Skip to content

Add-on packaging spec, part 3

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.

Spec corrections

  • 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!

{ 5 } Comments

  1. Benjamin Smedberg | 2010/05/21 at 7:20 PM | Permalink

    What manifest? Why does there need to be a manifest?

  2. jorge | 2010/05/22 at 10:59 AM | Permalink

    @Benjamin: if you’re referring to the manifest of the big JAR file, it would be necessary to determine chrome resolutions, overlays and others, just like manifests in individual add-ons.

  3. Mossop | 2010/05/24 at 12:51 PM | Permalink

    A HTML based manifest seems just plain wrong. You’ll basically be misappropriating all the HTML syntax tags for your own purposes leaving something that probably makes no real sense, or creating your own tags in which case you aren’t really using HTML. Not to mention the fact that we actually have no easy way to parse HTML documents in the platform right now (crazy I know).

  4. jorge | 2010/05/24 at 1:00 PM | Permalink

    @Mossop: the idea would be to limit the manifests to be strict XML instead of any kind of HTML. It wouldn’t be using custom tags, of course, but regular tags like <p> and <ul> with “id” attributes identifying what the purpose of each node is. It’s a bit of a stretch semantically, but it would help by bringing lots of familiarity and IDE support to the mix.
    Considering that the manifest format would be a very limited subset of HTML, there would be no need to have an HTML parser process these files. A regular XML parser would suffice.

  5. Mark Finkle | 2010/05/25 at 10:02 PM | Permalink

    I don’t think using HTML would bring lots of familiarity and IDE support because it’s too much of a stretch semantically. Using HTML like this might be fine for microformats, embedded in an HTML page, but for a standalone file, I don’t see the benefits over a simple, specific XML dialect.

Post a Comment

Your email is never published nor shared. Required fields are marked *