If you are the owner of a Hotmail email account and a Blackberry (I own neither, but my uncle had the former for years and acquired the latter a couple of weeks ago to get his emails faster) you may have already tried forwarding your mail from one to the other, perhaps because the person at the store told you it works with *all* web mail services (as was the case with my uncle), merely to discover the sad truth: it doesn't!
Open source to the rescue. After a bit of looking around I found this great little POP3 server proxy called FreePOPs. What this great little program does, is it allows you to retrieve your free web mail messages with any application or device that supports the POP protocol (including a Blackberry). The best part is that it works with most popular free web mail providers out of the box (and some less popular ones too) and it is extensible, so in theory support could be easily added for almost any service. It's also very light and very much in the background.
While this is an easy way to get your Hotmail messages on your Blackberry, it can also be used to get them in your Gmail inbox. Gmail's options include retrieving emails from a different account that supports POP3 access. The only downside with Gmail's POP retrieval is that you don't get to control how often it checks - which at times could mean as long as an hour between checks. Still, it sure beats paying for Hotmail Plus just to be able to forward your mail.
Pesky email problems like these are all too common, which is also why I'm posting this up in the hopes that this might be of some use to people out there looking for a similar solution.
You can find a download link for the program as well as more info right here.
Thursday, April 24, 2008
PW Core/Extension Docs Up
So PW Core is finally in the tree and is available in nightly builds as of April 24th, 2008. The extension is also up and running on Mozilla's addons website and can be downloaded here.
I have also created draft support documents for both PW Core and the extension:
PW Core
PW Extension
As always, your feedback is appreciated!
UPDATE:
The article on PW Core has been generalized and moved to MDC. Find it here.
Also, thanks to Cesar, my extension went public on AMO. See link above for download page.
I have also created draft support documents for both PW Core and the extension:
PW Core
PW Extension
As always, your feedback is appreciated!
UPDATE:
The article on PW Core has been generalized and moved to MDC. Find it here.
Also, thanks to Cesar, my extension went public on AMO. See link above for download page.
Friday, April 18, 2008
PW v1.0 and Final OSD700 note
Well this certainly feels a little strange. I am now technically a CPA graduate - but its not really sinking in yet. PW v1.0 is done and I must admit I'm very happy with the end result. It has certainly come a long way since last September. You can find all the info on this new release on my wiki as always.
Now I would like to thank the many people who have been a part of my journey and helped me along (in no particular order):
Dave (humph), Chris (ctyler), Robert (roc), Mark (mfinkle), Mike (shaver), Gijs, Armen (armenzg), Cesar, Andrew, Lukas (lsblakk) and Ted (for his extension making script -- really useful!!).
Thank you all and I hope I'm not forgetting anyone!
Now I would like to thank the many people who have been a part of my journey and helped me along (in no particular order):
Dave (humph), Chris (ctyler), Robert (roc), Mark (mfinkle), Mike (shaver), Gijs, Armen (armenzg), Cesar, Andrew, Lukas (lsblakk) and Ted (for his extension making script -- really useful!!).
Thank you all and I hope I'm not forgetting anyone!
Wednesday, April 16, 2008
PW Extension v0.91 is out
A new extension is now available. Here are the changes that occurred since the last update (v0.9):
Please note: the latest extension only works with the latest PW Core patch (v0.91).
Find the download link and installation instructions on the project wiki.
- The extension can now be enabled/disabled directly from the status bar icon.
- A new popup notification appears above the status bar meter if a consistent high run time is detected.
- The extension now listens for the new "experimental-notify-plugin-call" topic name
Please note: the latest extension only works with the latest PW Core patch (v0.91).
Find the download link and installation instructions on the project wiki.
PATCH going "experimental"
There has been some discussion surrounding my patch among the more senior developers at Mozilla today and as a result I have been commissioned to change a small part of the code. The part in question is the topic with which a plugin's run time value is broadcast through the observer service.
Formerly known as 'notify-plugin-call', it is now named 'experimental-notify-plugin-call'. This change may seem small or insignificant but it actually makes a lot of sense, especially when you consider that the way the run time is currently determined and communicated is almost certain to change in future releases. This change will also mean a new version of the PW extension as it needs to be adjusted to the new topic, but the new version will also incorporate some improvements to the UI as well.
A number of people have also noted that in the performance test charts I have posted recently, the y-axis does not start at 0. Admittedly this was a bit of an oversight on my part, especially since when you do have the y-axis start at 0 my case for PW becomes much easier to make. I have therefore recreated the chart for the two tests I posted earlier - this time with the y-axis properly labeled:
Formerly known as 'notify-plugin-call', it is now named 'experimental-notify-plugin-call'. This change may seem small or insignificant but it actually makes a lot of sense, especially when you consider that the way the run time is currently determined and communicated is almost certain to change in future releases. This change will also mean a new version of the PW extension as it needs to be adjusted to the new topic, but the new version will also incorporate some improvements to the UI as well.
A number of people have also noted that in the performance test charts I have posted recently, the y-axis does not start at 0. Admittedly this was a bit of an oversight on my part, especially since when you do have the y-axis start at 0 my case for PW becomes much easier to make. I have therefore recreated the chart for the two tests I posted earlier - this time with the y-axis properly labeled:
Test 1
Test 2
Tuesday, April 15, 2008
What a day...
So this morning I submitted my pre-final core patch for review and got some very positive feedback. In fact it seems that as far as the core patch goes it will remain mostly the same from now until the 1.0 release. It is also ready to be checked into the tree but will most likely not make it into FF3.
In addition to releasing the latest patch, I had also created a performance test that allows a user to time how long calls made from JavaScript to an exposed Actionscript function take. The idea behind this was to run the test on a fresh build and then run this same test on a build that includes my patch. By comparing the two, it should be possible to determine what sort of overhead my code creates.
Below are the latest 2 tests that I have run:
Here is the result from test run number 1
And some screen shots:
Test number one was run on minefield 3.0pre, with PW OFF running first.
And here is the result from test run number 2
And some more screen shots:
Test number two was also run on minefield 3.0pre, with PW ON running first.
What these runs suggest is that the overhead that is created by my code is so minute that the difference simply "drowns" in the noise. As Chris Tyler (ctyler) put it, that places it firmly "into [the] 'who cares' territory". I tend to agree!
In addition to releasing the latest patch, I had also created a performance test that allows a user to time how long calls made from JavaScript to an exposed Actionscript function take. The idea behind this was to run the test on a fresh build and then run this same test on a build that includes my patch. By comparing the two, it should be possible to determine what sort of overhead my code creates.
Below are the latest 2 tests that I have run:
Here is the result from test run number 1
PW ON | PW OFF | |
Test 1 | 3135 | 3174 |
Test 2 | 3144 | 3156 |
Test 3 | 3139 | 3130 |
Test 4 | 3140 | 3175 |
Test 5 | 3161 | 3135 |
Test 6 | 3144 | 3153 |
Test 7 | 3156 | 3173 |
Test 8 | 3154 | 3139 |
Test 9 | 3146 | 3165 |
Test 10 | 3153 | 3154 |
Average | 3147.2 | 3155.4 |
And some screen shots:
Test run with PW OFF:
Test run with PW ON:
Test 1 data plotted on a bar graph:
Test number one was run on minefield 3.0pre, with PW OFF running first.
And here is the result from test run number 2
PW ON | PW OFF | |
Test 1 | 3176 | 3142 |
Test 2 | 3399 | 3160 |
Test 3 | 3197 | 3137 |
Test 4 | 3142 | 3159 |
Test 5 | 3155 | 3137 |
Test 6 | 3172 | 3141 |
Test 7 | 3152 | 3167 |
Test 8 | 3177 | 3148 |
Test 9 | 3166 | 3148 |
Test 10 | 3165 | 3162 |
Average | 3190.1 | 3150.1 |
And some more screen shots:
Test run with PW OFF:
Test run with PW ON:
Test 2 data plotted on a bar graph:
Test number two was also run on minefield 3.0pre, with PW ON running first.
What these runs suggest is that the overhead that is created by my code is so minute that the difference simply "drowns" in the noise. As Chris Tyler (ctyler) put it, that places it firmly "into [the] 'who cares' territory". I tend to agree!
Tuesday, April 1, 2008
Demo 2 and PW Extension v0.9 + screenshots
So in my previous demo (demo #2) I showed Dave what was then the initial concept for the plugin activity meter. Since then I had fixed some bugs and removed a substantial amount of code.
I have decided to remove the plugin recorder feature from the extension as it would not be of much use to most end users. Instead I'm considering making the recorder into its own extension, in case anyone would find that sort of thing useful. The recorder is in fact its own class, and should be easy enough to transplant into an existing extension skeleton; for now however, there are more immediate issues I must tend to, so this will be on the back burner for now.
A lot of the missing code can also be attributed to the old method by which PW made the decision to notify the user of a high runtime. The new method is much more compact - considering it consists only of about 45 lines of code vs. the old method totaling almost 120 lines. The major difference between the two methods is in the usefulness of the information each provides. The old method sampled the runtime values over a given period of time. If a runtime of 'x' or more was reported 'y' or more number of times, the system would notify the user that the plugin might be consuming too many resources. The current method by contrast samples the runtime values within a given period of time, totaling them and then calculating this as a percentage of total time (the sampling time). The new method makes away with most all of the somewhat clunky settings in the previous extension and it also allows for a far more informative graphical representation of the load compared to that of the old method.
So now for some screen shots of the new graphical components:
Now that the extension is taking shape for the 1.0 release and the core patch is inching closer to the tree, I'm going to concentrate on getting the performance testing under way. In the meantime feel free to try out the extension for yourself. The details are on the project wiki page: click here.
I have decided to remove the plugin recorder feature from the extension as it would not be of much use to most end users. Instead I'm considering making the recorder into its own extension, in case anyone would find that sort of thing useful. The recorder is in fact its own class, and should be easy enough to transplant into an existing extension skeleton; for now however, there are more immediate issues I must tend to, so this will be on the back burner for now.
A lot of the missing code can also be attributed to the old method by which PW made the decision to notify the user of a high runtime. The new method is much more compact - considering it consists only of about 45 lines of code vs. the old method totaling almost 120 lines. The major difference between the two methods is in the usefulness of the information each provides. The old method sampled the runtime values over a given period of time. If a runtime of 'x' or more was reported 'y' or more number of times, the system would notify the user that the plugin might be consuming too many resources. The current method by contrast samples the runtime values within a given period of time, totaling them and then calculating this as a percentage of total time (the sampling time). The new method makes away with most all of the somewhat clunky settings in the previous extension and it also allows for a far more informative graphical representation of the load compared to that of the old method.
So now for some screen shots of the new graphical components:
First what it looks like in its inactive state.
Active, with a plugin running.
Various flash content.
Youtube video playing.
Flash video loading.
Flash based game.
Can't forget the new and compact settings dialogue.
Now that the extension is taking shape for the 1.0 release and the core patch is inching closer to the tree, I'm going to concentrate on getting the performance testing under way. In the meantime feel free to try out the extension for yourself. The details are on the project wiki page: click here.
Subscribe to:
Posts (Atom)