This is a specification for a project that will be implemented for the Google Summer of Code, and it can still change as feedback is received. There are no concrete plans of making this a part of Firefox in the near future. Read my previous post for more info.
Part 3 – Installation
Add-on performance has been a hot topic recently, given that add-ons are a significant contributor to slowdowns, specially at startup. One of the reasons I’ve seen mentioned is how extensions are laid out in the file system after installation. The suggestion is to educate developers on how to package add-ons taking performance into account. That’s not a bad approach, but I think it’s easier for developers and more effective in general if the post-install procedure handles performance optimizations. This might even be necessary, considering that different applications and different platforms can have different ways to optimize for performance.
The add-on installer should package most if not all files into a single, uncompressed JAR file, as suggested in this bug report:
- Add-ons in the new format should not have internal chrome JARs.
- All files that can be efficiently read from a JAR file will be moved into a single uncompressed JAR (like a TAR) upon installation. This is a single JAR for all add-ons using the new system. One possible “cheat” to accomplish this is to create a fake add-on install directory, with a single JAR and a generated manifest that includes the information for all add-ons contained in it. This manifest could even be an “old style” chrome.manifest, in case changing chrome resolution rules turns out to be too difficult.
- Files that can’t be put in the JAR (this is mentioned in the bug report, and I don’t know why this is the case), such as binary libraries and components should ideally be grouped together in the same place where the big JAR will be located. One concern here would be file name collisions and the way these files are automagically loaded from their special folders, which may be hard to overcome. In case this is too difficult, it’s probably best to lay them out like it’s done now: on their separate extension directories.
From a performance perspective, this is what makes most sense for all platforms as far as I know, so it would be the default and maybe only behavior. However, if different packaging requirements come up for specific platforms, it can and should be implemented, with the great advantage that it will be possible to do so, at least with add-ons using the new system.
- By far, the most debated point in this spec has been the format chosen for the manifest. I’m convinced now, JSON was not the right way to go. I really like John J Barton’s idea of an HTML manifest, so I think I will pursue this approach. It makes sense due to familiarity, IDE support and even skinability. Somebody mentioned that I should also cover update.rdf and McCoy. This will be done in the new XML-based spec, and it should be very straightforward.
- In part 2 I mentioned that having internal JARs would still be possible. I’m reconsidering this decision. Since the new format is meant to be a fresh start in several regards, I’m thinking it would be a bad idea to drag these old practices back, considering that they would have a negative effect on the post-install process.
The final project spec will be moved to a wiki, where it makes more sense to have a document that will likely see many iterations and corrections. I will being working on this as soon as possible, and will post a link in this blog once there’s something everybody can look at.
I will also post updates when there’s more progress on the project.
- Google, for creating the very cool GSOC and keeping it alive for many years.
- Gerv, choffman, and all GSOC admins.
- Hebert Duarte, for volunteering to implement this project.
- Everyone who has been posting comments and giving me feedback. It’s all very valuable and not a single comment has gone unread.
Thank you all!