Tag: development

Categories
Mozilla

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.

Categories
Mozilla

Anyone else think some dev’s don’t blog enough

I say this because all to often, Ben Goodger’s checkin’s make me curious 😉

XPInstall UI… Not done just yet but getting closer.

That’s about all we see. No screenshots, no blogging.

Some of the Bugzilla bugs are rather vague as to whats being done. Not to much details. IMHO it would be nice to start seeing some more documentation of the day to day changes, in more understandable terms. The Burning Edge is a great website for day to day stuff, but not to much information on each thing. Just a mention.

Not a “complaint”, or a “criticism”, or intended to start a flame war, or a giant thread over at Mozillazine . It’s purely intended as a suggestion for anyone looking for a good way to unite the community a bit.

I think since the Mozilla Foundation formed, the communication went down a bit. Not sure if that’s because more contributions are coming from remote computers, rather than Netscape. Or perhaps it’s pure overload of work over at Mozilla Foundation Headquarters as Asa notes.

In any regard, I hope after the holidays, when things settle down a bit, we see some more. First David Hyatt got sporadic with posting, then many followed.

I’d say one of the best sources right now is Henrik Germal’s Blog. A real quality job in keeping everyone informed on what’s what.

Mozillazine is of course great as well, but not as nitty gritty on the dev work as Henrik can be. With good reason, they tend to orient more toward the general community, rather than the ubergeeks.

Categories
Apple Security Software

Apple’s Life Cycle and Security

I don’t think I need to say I’m a Mac lover. I’ve been very satisfied with my Macs, and love OS X. But I got to agree with CNET about Apple’s recent trends.

Product Life Cycle
Apple’s been pretty firm about the 5 year rule for hardware. After that period, your not really getting hardware support. It’s a pretty solid rule, and one you can depend on (for good or bad). Developers, both hardware and software are well aware of it.

Unfortunately, there is a lack of an official product life cycle for software. Microsoft has a clear product life cycle. I sincerely hope Apple matches Microsoft and adopts a similar policy. For at least that length of time (if not longer), and sticks to it. The mystery involving product life is a real turn off for companies. How can you evaluate what Macs will cost? A good security issue may require the entire office upgrade their OS version. In such cases, a product cycle would allow an IT department to know very well what it will cost to keep Macs afloat. And dispel some cost myths.

I would like to propose a Security/Product Cycle Policy for Apple to adopt:
A product will be officially supported for 5 years after general availability. During this time, full support will be provided. This is the same as Microsofts policy. During this time. All security and bug fixes are available. No new features are required (though could be offered). For example, a WebCore update would fall in this category. Keeping Safari up to date and fixing rendering bugs. New OS X features such as Exposé, would not. That’s for a new product, and new product cycle.

A Security Phase would proceed for a period of minimum 2 years, during this time, only security bugs will be fixed. Keeping Safari up to date, and fixing crashes wouldn’t qualify. Only bugs that provide a security risk.

So in theory, a company can have a system for 7 years, and be able to maintain it for the original cost. Of course they will most likely want new features, and would upgrade in that time. But they have a buffer up to 7 years. This compares with Windows XP’s current product cycle.

A very inclining offer for IT departments. Buy a pretty powerful computer, and know for 5 years you have hardware support for new OS versions. For 7 years, your current OS will be secure. And we mean Mac OS X secure. Not Windows Secure 😉

Apple needs to use it’s strong point. A solid UNIX security model. Take advantage of the fact that it can do so. Security is a big advantage the Mac platform has. It will cost more to support older OS’s. But in the end, will make the OS much more attractive than it is now.