It has come to my attention that the maintainer of the Debian Mozilla packages (Mike Hommey) is using patches that significantly alter the XULRunner linking strategy (first discussed here).These patches cause various Mozilla libraries to be soversioned and installed in the library path (/usr/lib). Although I have emailed Mr. Hommey privately on a number of occasions, I have not received a reply, and the linking strategy that he has implemented is poorly thought out and will lead to instability and frustration. (more…)

After years of planning, preparation, and coding by numerous people, a stable developer preview of XULRunner has finally been released!

Although the concept of a generic XUL application launcher or XUL Runtime Environment had been talked about for a long time, the practical beginning of the project can be dated as the first commit of nsXULRunnerApp.cpp to CVS by Darin on Aug. 26, 2004. Since then, a growing community of developers has improved and stabilized XULRunner to the point where various software projects are actively developing applications on top of the platform.

This stable preview release is an exciting milestone, and I am looking forward to the XULRunner 1.9 release, which will be the first production release which will ship with and serve as the application launcher for Firefox. I recently got the build system set up so that you can build Firefox-on-XULRunner, and once I get a few bugs taken care of I hope to have tinderboxes and nightly builds of Firefox-on-XULRunner available for early testing.

This past week I’ve written a couple of patches to make embedding Mozilla easier/better:

1. Bug 321359 – Give embedders the ability to lock and select profiles
2. Bug 299988 – Integrate gtkmozembed with libxul

This second patch caused some concern: I made gtkmozembed use the new toolkit profile-management APIs (gtkmozembed will no longer build with seamonkey). This is not a problem of itself, since Mozilla has already made a commitment that libxul will be the ongoing embedding framework.

The more difficult problem is that the toolkit (xulrunner) currently doesn’t support a lot of the “small-device” build options such as --disable-xul. We definitely want to continue to support small device embedding situations, while avoiding the costs of supporting an exponential combination of little build options that may have complex interactions. This provoked a spirited discussion among drivers@mozilla.org about what options are valuable to support and who should bear the support burden of these options. The provisional outcome of this discussion is as follows: Mozilla is interested in maintaining a couple of “small device profiles”, in cooperation with small-device embedders (cell phone manufacturers and others). I have written up a wiki document with a preliminary proposal describing three profiles. I would like to get input from small-device embedders about what features they actually need, and to what extent they are able to help in the maintenance and documentation of these small-device profiles.

This proposal results in a slightly illogical situation of a small-device “XULRunner” build that doesn’t actually support XUL (it would be an embedding solution). In this sense what you are building is really more “GeckoRunner”; but there’s no need to get caught up in naming…

I’d also like to reiterate that this support is explicitly for small devices that can’t handle the full XULRunner footprint. It doesn’t make sense to have a small-device profile of XULRunner installed on a PC; it is important to support a full-featured web if there are sufficient system resources available.

I have taken a recent set of XULRunner 1.8.0.1 tinderbox builds for intensive testing candidates before the release of XULRunner 1.8.0.1. Please download and test these builds. See the XULRunner roadmap for details about release schedules and future plans.

One of the most frequent and persistent complaints about XULRunner is that I have explicitly excluded support for client/server SQL databases. Some have even gone forth to say that lack of proper database access in the platform will be it’s Achilles’ heel. And so I’m going to try and address this issue head-on:

XULRunner does have a database strategy: the platform will provide support for a SQLite embedded database API reflected into XPCOM. It will not include support for client/server database mechanisms such as MySQL/Oracle/etc. This reasons for this are fairly simple: The primary targets of XULRunner are twofold: support the Mozilla rich-client apps (Firefox and Thunderbird); and allow innovation of networked rich client apps based on web technologies. Client/server databases really don’t have any part in this strategy; Mozilla would not have any real testing/QA framework for this code if it were included. We need to keep a lean and focused platform that does not try to solve everyone’s problems.

Having said that, there are a couple solutions for doing client/server database access:

1. Jan Varga has done client/server database code which lives in extensions/sql. If an app really needs client/server database access, it can ship the SQL extension with the application; I’m going to work with Jan to get this code into shape as a real platform-level extension and make it available on http://addons.mozilla.org/.
2. It’s not that hard to write a web proxy which takes SQL, performs a query, and returns the results as XML: AJAX-style web apps could use this to perform SQL-based queries over XMLHttpRequest. This will be even more useful once Neil Deakin completes the template work.

I’ll have a few cool XULRunner demonstrations up shortly, including a popular AJAX-style webapp in it’s own XULRunner process (hopefully with minimize-to-tray and everything), and the beginnings of some dashboard-like widgets written in XUL+SVG that are loaded directly from the web and have web-based security permissions.

I am not a skilled graphic artist. This is by no means a “final” XULRunner logo. I just created it in my spare time and it is a lot of fun:

In case you don’t remember your Greek mythology, Atlas was condemned to bear the heavens upon his shoulders by Zeus as punishment for leading the Titans in their war against the gods. I thought that the idea of holding up the Firefox globe was a fitting visual metaphor for XULRunner.

People frequently send me e-mail to ask me questions or discuss XULRunner. While this is not an entirely bad thing (I like hearing what people want from XULRunner and the Mozilla “platform”), it gates a lot of discussion through me, which can slow things down considerably. I would like to recommend the following communication channels for people who have general things to ask about XULRunner:

• For general development questions pertaining to XULRunner applications, let’s use the netscape.public.dev.xul newsgroup;
• For questions about using XULRunner in embedding contexts, use netscape.public.mozilla.embedding;
• For discussion and planning about the development of XULRunner itself, I have created a semi-private mailing list XULRunner-dev@mozilla.org. This list is meant for serious developers who are working on XULRunner’s design and implementation. The archives are public, but list membership is by invitation only. If you would like to be part of this list, please email me privately and let me know.

I would also like to encourage XUL application developers to write articles for the XULRunner section of the Mozilla Developer Center. Writing XULRunner apps is pretty simple, but only if you have a good guide to get you started!

Update

The newsgroup hierarchy has changed. XULRunner discussion now belongs in mozilla.dev.platform, mozilla.dev.tech.xul, or mozilla.dev.embedding.