Blue Screen Of Duds

Where the alter ego of codelust plays

Archive for January 6th, 2007

The case for a Firefox Gmail client extension

leave a comment »

With average payload sizes for the new and Ajaxified and funkalicious free email providers weighing in at upwards of 300KB, is there really a case that can be made for a mail client that can be written as a Firefox extension?

Last I checked, Gmail’s core Javascript component was around 360KB in size, Windows Live Mail was over 400KB and while I have not checked out the new Yahoo! Mail beta, I’d be surprised if it was any lighter than the other two.

I have nothing against massive Javascript files being pulled down from servers with every new browser session (Gmail does it, so does Windows Live Mail and I can’t understand why they are not ever cached), but it is highly improbable that the core is changed five times in a day, necessitating this data transfer. And what’s worse, for that additional data transfer, you don’t get anything different.

It is the same UI, the same functionality, while the only data being transferred should ideally be the message content and message counts. Mind you, I am not making the case for a full fledged email client. I am taking more about something on the lines of the Gmail mobile client that already has the UI loaded within the application, saving you from downloading the same data over and over again.

The extension angle is not a silver bullet though. I can’t ever see a Microsoft doing a Firefox extension or even a plug-in for Internet Explorer. They already Windows Live Mail Desktop, which has a terribly confusing positioning as it is. Last thing they’d want is to have a Windows Live Mail Desktop Lite. Yahoo! might not want to do it because of the money they paid to acquire the IP required to power their beta product.

That leaves us with Google, which has a history of going off the beaten track with product development and features. But an XPI road to a client is not without problems, some of which read like this:

1) Protecting Proprietary code: From what I’ve seen there is no way to encrypt the source code of an XPI. You do have closed source XPIs, but they are not the same as the code not being available. That said, all the Ajaxy interfaces use Javascript that’s not obfuscated, at least to the degree where it is not possible to dig out the source.

2) Encryption: Not really an issue. You can very comfortably pass back and forth the XML/JSON messages over an HTTPS connection.

3) User experience: This one is a bit of a killer. A lot of normal users don’t often update their XPIs. You can always write in hooks that would disable functionality after a version check that returns a true value. While for the bulky Javascript approach all users get the latest UI, whether they like it or not.

4) Tough to replicate on IE: I would love to believe that there is no business angle to this, but that’s not the case. With Firefox adoption still in the sub 30% levels, it is important to have Internet Explorer support for any product you are looking to be consumed by the masses. It sucks, most of life does, so just get used to it and move on.

Thoughts, anyone?


Written by shyam

January 6, 2007 at 12:08 pm