Extensions… The Next Generation

I’ve begun thinking about what’s good, and what’s bad about extensions, and what I would ideally like to see. So I put together a somewhat brief analysis. Since now is about the time to start bringing about ideas for improvements, I figured I’d take a little stab at how to make extensions kick even more butt.

My goals and thinking were based on the following principles:

• Users hate unnecessary steps. Less to do the better
• Developers want users to upgrade extensions quick so they don’t have so many versions floating around

Enough background, here’s my proposal:

Uninstaller

Should keep a log in a universal format, and a widget from within the application (FireFox, Thunderbird, NVU…) should be able to read and uninstall based on it’s info.

Version Checking

Each extension should have a manifest stating a URL where the application can check for updates to the extension. This way, like any other application, Mozilla apps can look for updates and tell the user when an update is available. Ideally these update URL’s would be hosted at mozilla.org and updated by a web ui that developers can signup for access to. Perhaps use a remote XML query interface to check for the version, and download URL. Once an update is found, it can be auto-downloaded, and prompt the user if they wish to update now (or later). When prompting, it will tell what version is installed, what the new version is, and changes since the last major release.

Smart Clean-installer

It’s a pain needing to find the extensions we use on a daily basis again and again after each install. End users don’t want to bother either. With the above Version Checking interface, perhaps the XPinstall can save read a master manifest saved by the application, clean the install directory, then once installing the new product, read the manifest and download the extensions previously installed. This way, users can upgrade to the latest and most stable version, without having to find those nifty extensions again and again.

Regarding that manifest and it’s XML query interface, here’s what I imagine it holding:

Manfest:
Name | Version | Version Check URL | Author | Homepage | Date Released

Master manifest would contain each extensions manifest in one large file.

XML Query Interface:
Name | Current Version | Min Mozilla Version Supported | Max Mozilla
 Version Supported | Version Override Allowed | Date Released | Homepage | Author | Changes

This of course would be accessed remotely by the application and processed in the background.

With the above info, the user could be told if the extensions supports their Mozilla version, what’s new, when it was released.

All in all the system would be rather inclusive. The user would no longer need to re-download their extensions every time. Nor would they need to check for updates.

It was discussed a while back to build a system that would from within Mozilla allow the user to browse a list of available extensions, then install them, all from within Mozilla, rather than search websites. A nice XUL based directory. That could be added at a later date to integrate with this proposal.

I think the above would prove rather nice. There’s an obvious benefit to the users, and to the developers, who get a smoother distribution channel.

Obviously the download URL could point to a script redirecting to a random mirror, allowing sites like mozdev.org to keep bandwidth costs down.

So, I leave my proposal in the public domain, in hopes that someone may read it, break it down, and perhaps enhance and improve upon my model.