XULRunner Versioning

Overview

This document details a versioning plan for XULRunner (see: XUL:Xul_Runner).

The problem: Since Gecko is a moving target, XUL apps running on top of XULRunner may make use of Gecko specific features and APIs that are not frozen. XUL and most of the XUL toolkit are an excellent example of a central API that is for the most part not frozen.

The Plan

This problem has been solved for Firefox extensions via the Extension Manager. The install manifest of a Firefox extension includes a range of Firefox versions where the extension is expected to work. When the Extension Manager encounters an incompatible extension, it alerts the user and gives them the opportunity to fetch a compatible version of the extension.

For XUL applications, the Extension Manager solution is probably not going to fly. Users will not be happy if they need to upgrade all of their XUL apps when they install a new version of XULRunner (as part of the latest release of Firefox, say). Instead, we should try to support multiple installs of different versions of XULRunner.

Since we intend to invoke XULRunner via file extension association, we will only ever have one XULRunner instance associated with .xulapp files. That instance will most likely be the most recently installed version of XULRunner on the system.

We can solve the versioning problem by encoding compatibility information in the .xulapp file, and then have the invoked instance of XULRunner read the compatibility information and defer to (i.e., execute) another instance of XULRunner if appropriate. We would use the system registry or some custom registry depending on what the OS provides.

The mechanism used to locate different versions of XULRunner may be the same mechanism used to locate different versions of the embeddable Gecko runtime.

Details

The current system which is used to identify the paths of GREs is pretty good in theory, though its implementation sucks in practice. In particular, the reading and writing of the win32 registry needs to be a lot more thorough; linux distributors (Redhat) need to use /etc/gre.d/version so that RPMs will install/uninstall properly.

We should also make it possible for apps to work with "xulrunner version x.x and above", so that if they *are* using only frozen APIs, they will work with any available xulrunner.

Finally, I am surprised that we are planning on launching XUL apps mainly through a file association. I kinda expected that shell scripts and shortcuts would be the ordinary method of launching an "installed" app, and that the file association would mainly be used for apps that were newly-downloaded and not yet "installed" (or were still under development). --Bsmedberg 15:27, 16 Dec 2004 (PST)

Well, you make a good point. If we require shortcuts to be created that connect a XUL app to the appropriate XULRunner, then we do not need to worry about the wrong XULRunner being used to launch the app. However, it means that moving the location of XULRunner would require all XUL apps to be modified, assuming that shortcuts and shell scripts would have a hardcoded absolute path to the XULRunner instance. Some indirection might be nice. We would still need a solution along the lines of what I described here to deal with XUL app packages when they are to be installed. That means that we'd need to setup a file association for whatever the XUL app package file type happens to be. I also figured that a file association for .xulapp would make it easy to deploy XUL apps as simple ZIP packages that users only have to unzip to run. I know that our long-term goal is to provide an automatic install process for downloaded XUL app packages, so talk of "simple ZIP packages" is probably just an intermediate solution at best. Hmm... --Darin 17:34, 16 Dec 2004 (PST)

as for that RPM thing, couldn't they have some post-install script modifying gre.conf?

anyway... why make users explicitly install xul applications? consider java - I can double-click a .jar file on windows, or run "java -jar foo.jar" to run an application on linux. why must xulrunner be more involved? :-) --Biesi 13:23, 17 Dec 2004 (PST)

It need not be more complicated. In fact, it will be the .xulapp that people can simply double-click or pass to xulrunner on the command line. But, there are situations where having an install stage may be very desirable. Consider the Mac OSX .app "executable" directory. It'd be neat if a downloaded XUL app could be installed as a .app directory. Similarly, there may be other platform-specific things we'd want to do to install an application on other platforms. For example, I can imagine that it'd be nice to install .desktop files for GNOME users. It would be a pain if we forced people to create platform-specific packages in order to achieve these goals. Sure, they may already have platform-specific C++ components, but consider JS-only apps (like Chatzilla). It'd be nice if only one platform-independent package could be used to install the app anywhere, while still installing the app as a native app would be installed. --Darin 14:47, 19 Dec 2004 (PST)

There are another important advantage of installing XULRunner application, ever if it's only XUL+JS - ability to install extentions. If you are running directly from .xulapp archive it's impossible to use current model of application-wide (not user-wide) extention installing. MichaelDubner 12:26, 9 Feb 2006 (PST)

I don't think it is a good idea to use the .xulapp extension. I am already running a project at http://xulapp.mozdev.org to create an FF IDE. I already use this extension for configuration files.

I withdraw this objection. It appears that XulRunner will be perfect for the XulApp IDE. In fact, XulApp may serve as the application builder your plans reference. I would like to get in touch with an XulRunner developer. Please email me at pwilson@gorge.net I believe we will find some common interest.

May I suggest to consider the ability to link an extention for data files with a XULrunner app? --Kaj Kandler 2006-04-12 9:17 EDST