Add-ons Manager session notes

My head is slightly less fuzzy now and I’m almost back on UK time so I thought it would be a good opportunity to give a quick review of how the Add-ons Manager session I ran at the summit went. I won’t go into too much detail, just a look at the main points of discussion and how I felt the room reacted to the ideas. You can also see the slides I prepared or the notes that Basil kindly took for me without me needing to remember to ask. Most of the session was about things we might want to implement and what problems/benefits we might encounter.

# Add-on locale packs

The idea of developing the UI for locale packs specific to extensions received a less enthusiastic response than I had expected. This may have been because there were more add-on developers and less localisers in the room, but the general feeling seemed to be that there was not a large benefit and the potential complications, particularly around updating, could cause some large problems.

# Dependency resolution

The current add-on dependency implementation is a very rough start. Being able to automatically find and install dependant add-ons for the user, with clear UI to show what is happening, seemed to be something that didn’t have many downsides. There were also suggestions that AMO could handle dependencies and deliver sets of add-ons as multi-xpi packages, though this could cause issues in upgrades.

# Add-on conflicts

The moment I mentioned the suggestion of a system to mark two add-ons as incompatible with each other half the room said they wanted it. It was pointed out that some add-ons were already disabling things they don’t like on install (if you hear of that happening without appropriate warning please let us know). It was also quickly realised that under the author’s control it could just become a means to avoid having to work to fix incompatibilities and to disable the competition. The suggestion of Mozilla maintaining a central list of incompatibilities seemed like a good way to go.

# Install without restart

No surprise that this was seen as useful, particularly in non-Firefox applications that don’t have the wonder of session restore. We also started talking about the potential for lower impact extensions that just had a small sandbox to work in with a little piece of UI which could make loading and unloading dynamically far easier.

# Install/uninstall hooks

We discussed how the current mechanisms for running setup and cleanup code for extensions were poor, there is no way to deal properly with uninstall in all situations. It was felt that add-ons should be able to provide a full uninstall script that would even run if uninstalled when disabled or in safe mode, but would not run if the add-on had been blocklisted. We also talked a little about sandboxing what this script might be able to access.

# Replace RDF

I was surprised that there seemed little to no resistance to the prospect of introducing a new plainer XML form for install.rdf and update.rdf given some of the comments I had when I blogged about it last. We would of course still support the old forms for a time and make converters between the forms available. There didn’t appear to be any benefit in using JSON instead of XML.

Much of the rest of the slides were skimmed over as we had unfortunately run out of time by this point, but thankfully that was most of the more important stuff completed anyway. For the immediate future I think introducing replacements for RDF into Firefox 3.1 is potentially on the cards. None of the other items were ruled out, far from it, though the locale packs seemed less interesting to everyone, and I think there needs to be some very careful thought about the prospect of running an uninstall hook for an add-on in safe mode or when disabled.