Delivering XUL
Mozilla is a very flexible beast. We will have a quick look at the various ways to deliver an application to your users.
XUL files can be either hosted locally on the same system Mozilla executes on. They can also be fetched from a remote resource such as a HTTP server. The table below shows strengths and weaknesses of each method.
| Feature | Files over HTTP | Signed JAR over HTTP | Local files in chrome |
|---|---|---|---|
| Dynamic Generation (1) | yes | - | - |
| XPCOM Access (2) | - (3) (4) | possible (4) | yes |
| Easy Updates (5) | yes | yes | possible (6) |
| Chrome cache (7) | - | - | yes |
| Suitable for | web/development | web/Intranet | Intranet |
(1) XUL being generated on the server-side, e.g. using XML_XUL. Usually not feasible.
(2) If you cannot acquire XPConnect privileges, you also don't have access to any of the other Mozilla privileges. Basically your application will be unable to interact more closely with the user's system.
(3) Mozilla's configuration can override this behaviour; it is dangerous though and not recommended.
(4) Users often inadvertently deny giving the application more rights, thereby increasing support costs and causing user frustration.
(5) Referring to rolling out new software releases without user interaction.
(6) If Mozilla is installed on a centralized share/network filesystem, you can deploy applications without involving the user. Otherwise, software needs to be distributed as Mozilla extension (tutorial).
(7) The chrome cache significantly improves memory usage and rendering speed of XUL-based applications. More about this here.
