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.

19 thoughts on “Add-ons Manager session notes”

  1. Oh yes please, please, please, kill install.rdf and update.rdf in their RDF forms. I am very serious here.
    Please think simple, and even stupid : minimal use of namespaces, no prefix, and so on.
    YAY !

  2. Unfortunately your talk was against a l10n specific session πŸ™

    About the “Add-on locale packs”, could you be a little more specific (maybe with a post)? We discussed this topic also in some l10n talks, for example talking about the opportunity of adding fallbacks (and Pike answered “no way” πŸ˜› ).

    Right now the main problem is that an extension with an incomplete (or broken, for example with wrong enconding) locale can break a significant part of the interface or even the whole browser: for example this happened some months ago with a very popular extension (I think it was WheaterFox, uploaded on AMO with a partial Italian locale), so we were flooded by requests in the Italian support forum.

    One of the suggestions was to add a compare-locale step when uploading an extension to AMO: if an extension has a broken locale, the extension is rejected (or missing strings from en-US are automatically added, even if a mixed english-localized interface is not really a good idea).

  3. I didn’t mention it in the session but I had to r- a TomTom HOME patch recently because it was trying to use E4X with install.rdf. Unfortunately, while RDF is an XML format it is also too “flexible” to apply the usual XML tools on it – you have to stick with the crappy API. Really looking forward to install.xml.

  4. Removing the install.rdf as a rdf format might be a good idea in the long run, I it is going to be a pain to have to keep both the install.rdf and install.something-new updated at the same time till Firefox 2/3 dies out.

    As to the Install/uninstall hooks all I can say is FINALLY!!!! It is about time. There should be an update hook as well.

  5. flod, the basics are fairly simple. It would allow locales for add-ons to be distributed as xpis the same way as you can for the whole application. It’s even possible right now but the UI is poor.

    We also talked about fallbacks, for property files it can be made to work but dtds just aren’t set up for it, I think we would end up having to change the localisation system extensions use to make that happen, which is obviously a massive shift.

    The compare locale step is interesting, it might also be useful to have some kind of standard tool that extension authors can test their own add-ons with, I know I was never good at properly testing the locales people submitted for my extensions πŸ™

  6. flod, the basics are fairly simple. It would allow locales for add-ons to be distributed as xpis the same way as you can for the whole application. It’s even possible right now but the UI is poor.

    Uh, like Enigmail… And I remember some problems with that strategy.

    Consider also that some users have a lot of installed extensions (for example more than 30), so they end up with more than 60 entries in their Add-on window (pretty unusable).

    About the common tools for developers, take also a look at this thread on l10n mailing list (running compare-locale locally)

  7. Exactly as I said, right now the UI is poor. That could be improved if we chose to, who says we have to list the locale packs in the main UI?

  8. I’m interested in locale packs for the main application, since I have en-US Firefox and Thunderbird with nl locale to be able to test/switch as an extension developer. Right now I have to always go to>/releases///, download the right %LOCALE%.xpi and restart %APP% before I can use it again.

    I was thinking about writing an extension that would auto update all installed locales and also enable/disable/switch locales much the same way as is possible for Themes, but when I mentioned that I heard there were plans to revamp the locale packs, possibly much the same way as I wanted.

    Do you think plans for restyling locale packs also for extensions will continue or was there so much negative response that those plans will be stopped?

    Doing this from an extension for the main application is probably a lot harder as I’ll need to override some xul and duplicate most of the existing definitions, which will be hard to keep in sync with new releases. Plus it will “force” the user to do an extra restart after installing/upgrading…

  9. who says we have to list the locale packs in the main UI?

    Well, I thought about the main UI because you have to:
    * display langpacks somewhere to allow their management (install/uninstall, update, activate/deactivate)
    * show in some way the link with the relative extension
    * manage the fact that this relation is one-to-many (strange people install one extension and two or more locales for the same add-on)

    Obviously we could use a different UI, or a mock-up of the existing Add-on UI to display locales without adding new entries for each language pack πŸ˜‰

  10. Dave, another thing discussed was the idea of update channels (e.g., where users could add a channel for beta/test releases. Think how Linux package managers, or I believe Eclipse has something like it. The main caveat would be trust/security, it would need to be made clear to the user that these channels are experimental.

  11. Yes, David, could you please comment on slide #14 (multiple update channels)? It’s my understanding that this should be multiple _nstallation_ and update channels, not just update channels. Would you agree with that statement? Also, I’d like to hear you comment on the bullets of slide 14… it’s not obvious to me what they mean.


  12. Because we were out of time and people were starting to leave when we discussed the update channels I didn’t really get a chance to either explain this properly nor to get any real sense about what people thought. But it is basically like nightly update channels, allowing you to choose between automatically receiving beta updates to your add-ons if you choose. The analogy is that for AMO hosted add-ons you might have a channel that lets you receive updates as soon as they are introduced into the sandbox to get the bleeding edge updates. I don’t consider this to be related to installation at all.

  13. > I don’t consider this to be related to installation at all.

    Ah, that’s a shame. In all the discussions I’ve had about this with various people (most of which took place the week before you talk at OSCON), everyone had the idea of installation and update channels. This would be similar to a typical linux package manager which allows the user to enter a URL for packages, with the default usually being the distro’s mirror system URL. Eclipse plugins use a functionally identical system.

  14. I only read about Add-ons Locale packs in the Slides/Release notes.

    Aren’t there any requests for adding more support for Skins to Add-ons? The default icons can look quite out of place when you use another Theme, so it might be nice to also be able to install/update extra skins for the add-ons. Preferably kind of automatic, so that the application checks the skins for all the installed theme-extension combination…

  15. Doing any compare-locales on the server will not be helpful for people getting their addons from sources other than AMO (say, mozdev, or random websites). I’m sorry, but fallback is pretty much required (yes, this involves hacking the bits that talk to expat).

    If taking the route of changing the whole l10n system instead (l20n?), then… maybe, but only if the rest of the app (i.e. mozilla-central) uses the same system. Mozilla has not, traditionally, been any good at maintaining things that have no users in the main tree.

    (Not having been at the summit, I have no idea what the turn out was like – I’ve heard there were lots of l10n folks; were there many extension folks that don’t work on the main apps or otherwise affiliated with MoCo?)

  16. I’m very interested on the story about extension langpacks – I unfortunately couldn’t make your talk, but talked with Basil a bit about them after his AMO talk. SeaMonkey 2 implements L10n for ChatZilla and venkman completely via langpacks that depend on those extensions.
    The support for those langpacks isn’t ideal on AMO, and could be improved in EM UI as well, but they technically work fine – we tested a lot before implementing this. If you have questions about details what we tested or so, just ping me.
    This also means that we have extensions that work with a number of products, including Firefox and dependent langpacks for those extensions around, if you need those for testing anything!

  17. If you’re going to go down the dependency management route, have a look at the OSGI/Eclipse scheme for plugins. They’ve worked through most of the issues with this particular problem domain.

Comments are closed.