Posted on by Mark Finkle

XULRunner Session – Summit 2008

We had a XULRunner Roadmap session at the Firefox Summit this year. Since the summit was limited to mainly Firefox community, I didn’t know how well a XULRunner session would be attended. However, the room was pretty full and we had a fair amount of XULRunner and Gecko embedding people in attendance.

I wanted to talk about what had been happening with XULRunner recently and what new things we could do in the short-term future (slides here). After a rocky start (XULRunner can be a touchy subject – let’s leave it at that), I think we ended up with some good action items:

  • Look into creating a XULRunner incubator repository: Many patches related to XULRunner, and the platform in general, could be risky to other Mozilla products. Getting patches landed in a tree, unit tested and checked for performance regressions would be helpful in getting them landed on the real tree.
  • Patch gardening: We have seen patches submitted by contributors not land quickly (for a variety of reasons) and then are forgotten when another opportunity opens. We need a way to find those patches without needing to clone Reed Loden.
  • XULRunner security fix lifecycle: Firefox releases get security fixes until Mozilla decides to end-of-life a release. Some applications could stay on XULRunner longer than the corresponding Firefox release lifecycle, exposing the applications to security holes. Obviously, the quick answer here is for XULRunner applications to keep current.
  • XULRunner localization: More specifically, language packs for the platform that could be shipped with XULRunner releases. This is an issue for Fennec too, so we might be able to get some good traction.
  • Improved documentation: Some form of printed (or PDF) documentation and a complete doxygen-like reference list.
  • Improved tool support: Some form of integration with existing IDEs to support Mozilla projects. Yes, Komodo has good support for this, but not everyone uses Komodo. Also, a simple command line scaffold generator, like that found in Rails, would be helpful for beginners.

There is already work underway in a few of these areas. If you want to find out more and start contributing, let me know. If you have more ideas, leave a comment. I’m looking for small, focused achievable ideas. I don’t want to boil the ocean.

6 Replies to “XULRunner Session – Summit 2008”

  1. Re: tools

    One of the Songbirders, Matt has written a Songbird Developer Tools extension that bundles together and adapts a couple of Firefox extension but adds a really neat Extension developer wizard that let’s you build a skeleton extension with the integration points you want built into it. I’ve been hacking on Mozilla for over seven years now, but I still find myself using that to create extension. It could be adapted beyond Songbird to be a generic addon skeleton extension.

    http://addons.songbirdnest.com/addon/68

  2. Ian : that extension lives for Firefox as well, but I am not sure how up-to-date it is.

    http://ted.mielczarek.org/code/mozilla/extensiondev/

    At Mozdev we are working on an initiative to get more tools into one place and keep them maintained.

    Mark, RE Patch Gardening. Do you envision a new role for someone in the community doing this. It does not necessarily need to be full-time. It could be possibly sponsored by MoFo and/or a group of interested parties working together.

  4. hmm.. I just got an idea for xulrunner applications and updating:
    would it be possible, being that xulrunner is currently in a subdirectory of most applications folders, to have xulrunner update, and then have the application it’s self release updates?

    In otherwords, two independent updates. The way to work around incompatibility there would be to auto generate a list of functions, or xpcom calls the application makes, and then check it against a list of changes, if an update has been provide to xulrunner that breaks a component, then the application doesn’t update xulrunner, but tells the user that the application may be compromised, as it isn’t compatible with the latest xulrunner.

    So a basic flow of that system would be:
    application -> check for updates:

    -> xulruner -> updates ? no; return : yes, download list of changes -> check compatibility -> is compatible ? no, return ; yes, continue updating xulrunner.

    -> application -> updates ? no, return ; yes -> check compatibility with installed xulrunner -> is compatible ? no, return ; yes -> download and install.

    Hopefully this makes sense; it does at the time of writing, and it’d mean that you know longer need to release a new version of your application when xulrunner is updated, if there aren’t issues.

    That’s my thoughts, anyone else?

  5. Pingback: Mozpad Post Mortem « davidwboswell

Comments are closed.