If you listen carefully to the Web 2.0 crowd, you will hear a disturbing undercurrent. They don’t just believe that the web is great. They believe that client applications are dinosaurs, dying relics of a programming paradigm that is irrelevant. I find this tendency alternately depressing and frustrating: not only is there a place for client applications, but it is a bright and promising future that can work in cooperation with the greatness of the internet.

Shaver is right: the web is great because it has fostered open cooperation, viral programming, coding by view-source, mashups and “being able to jam jQuery in the hole that used to have Prototype in it”. The internet provides an excellent medium for viral and open markup and programming. But this kind of programming does not need to be unique to the web, and the Mozilla platform is a great bridge between these two worlds.

Take a look at the Firefox extension system, for example. The extension system not only allows programmers to mashup the client, but it brings the world of view-source copy-paste development to the client in a way that is unprecedented. We can and should foster this same model of viral programming in client-side applications. This is the real power of XULRunner and the Mozilla platform, if we can tame and harness its complexity.

What does this mean in practice? The Mozpad (Mozilla Platform Application Developers) community has been working towards defining some projects and goals: I believe these goals should be evaluated in terms of their ability to bring web-style application development to the client. For example, a traditional “integrated” IDE is very poor at copying code from others and making it your own. If we really wanted to go down the IDE route (IMO we don’t) we should be thinking of features such as “I like this dialog, steal it” and integrated search for code patterns (from e.g. Google code).

Or, to take another example close to my heart, XULRunner application packaging. It is much more important to get a simple tool that can be used to package text files into an installer than worrying at all about compiling binary code. Binary code should be a minority and diminishing case in a viral-programming development model.

Even though Rafael Ebron claims that the rich client is dying, his point about offline web apps is important. The primary difference is of course the security and trust model: local apps have their run of the system and can perform complex network and disk activity (and install binaries if necessary), while offline web apps have to work within the bounds the browser has set out for them. Client apps are a complementary action for offline-enabled web applications, not direct competition.

I believe Mozpad should focus on the following high-impact investments:

• reducing the barrier to entry for developers (code and documentation);
• providing tools for viral programming (view-source, copy-paste, debugging and inspecting code)
• evangelizing the platform’s strengths

There is a bright future for client-side applications! We need to stay focused on the strengths of the Mozilla platform and the web paradigm and not be distracted by “RIA madness”, complex toolchains, or the need to imitate existing proprietary solutions.

In June 2003, Mozilla version 1.4 was released. For the first time, the Windows installers of Mozilla installed two separate pieces: the Gecko Runtime Environment (GRE) was installed into a shared location on the user’s hard drive, separate from the application components. Standalone installers for the shared GRE were made available so that other applications embedding Gecko could use the shared runtime. Life was full of promise… until users started upgrading or uninstalling their applications. The nightmare unfolded gradually: unsuspecting users would install a new version of Mozilla and Netscape or AIM would stop working. System administrators would install one version, and users would install into a different location, and both installs would fail to work correctly. It was not uncommon for the computer to become so horked that no combination of running uninstallers and installers would fix it: the only solution was to go into the registry and manually remove offending settings.

To this day, the phrase “GRE” conjures visions of frustrated users, unhappy developers, and unreliable instability.

The Perils of a Shared Runtime

This is the peril of a shared runtime, and one we absolutely must avoid. It is fiendishly difficult to get right, and the consequences of getting it wrong are devastating for users and developers alike. In March 2005, I posted a vision of how a shared XULRunner runtime could be implemented sanely. It kept registrations of installed runtimes and applications, and made sure that the correct version of the runtime was always available to applications. The XULRunner roadmap referenced this plan for XULRunner 1.9 and Firefox 3. Time has moved forward and we are now making hard decisions about features that were planned for Firefox 3, throwing many away because they do not fit in the schedule. The shared XULRunner runtime is one of those features.

This is the long story behind Mitchell’s post about XULRunner investment and Firefox 3. Mozilla is not “killing XULRunner”. It is merely stating the (obvious, I thought) fact that the previously published roadmaps are incorrect, and reiterating our support for continued development of the platform.

What are we doing?

Even though Mozilla isn’t going to ship Firefox 3 on a shared XULRunner, it is continuing active support of the Mozilla platform and the XULRunner project in particular:

• Firefox 3 might ship a “private” XULRunner. A private XULRunner is a standard XULRunner build, but rather than trying to share it between Firefox and Thunderbird and other applications that might wish to use it, each application woulds ship and update its own copy independently. We have had a tinderbox building FF+XR experimental builds for months. The major tasks left to turn this on by default are mainly packaging issues to make it install correctly, and landing places-bookmarks. But Mozilla isn’t willing to let the Firefox 3 schedule slip for a feature such as XULRunner, so it may not make it in time. Developers who are interested in helping make this happen should contact me!
• Make sure that prepackaged XULRunner builds are available.
  • If Firefox 3 ships on top of XULRunner, the build process will produce XULRunner packages “for free” without requiring the Mozilla release team to do separate release work.
  • Otherwise, I will be working with interested developers to make sure we have contributed XULRunner builds. This may take the form of build machines provided by Mozilla on the community network, or build contributed from elsewhere. The Eclipse AJAX Tools Framework community is already creating contributed builds of XULRunner 1.8.1.x; this is a natural continuation of that process.
• Linux distributions will be shipping Firefox on XULRunner. Several Linux distributions are already shipping XULRunner packages by default, for use by Epiphany and other Mozilla embedders. These distributions have already indicated that they are planning on distributing a shared XULRunner package and building Firefox 3 on top of this package. This will reduce the maintenance burden of Mozilla security updates significantly.
• Continue to support the XULRunner ecosystem. XULRunner is being used in a variety of new and exciting applications. Mark Finkle and I will continue to work with developers using XUL and XULRunner to uplift appropriate features and code back into the platform, as well as solicit, consolidate, and publish documentation. XULRunner is nothing more than two files which bootstrap an application and hook it up to the Mozilla toolkit: contributed patches help make life better for all Mozilla developers, including Firefox and its extension ecosystem. Perhaps something like MozPad would be helpful, though I would really like to get as much of that documentation back into the Mozilla Developer Center as possible, for shared consumption.
• Continue development in Mozilla 2. Mozilla 2 will have a clean separation between the XULRunner platform and the applications built on top of it. Having a clean API separation and build system separation between components will reduce the barrier to entry of new hackers for both the platform and the applications built on top of it. Whether this means we will have a shared runtime, or simply have better tools for producing applications on “private” runtimes remains to be seen.

The Power of Openness

I would like to extend a special acknowledgment to Ben Turner of Songbird for his continued support and patching of XULRunner and of the Mozilla build system. He recently asked me “how can I help make the Mozilla build system easier to use for external applications?” This is the kind of question that makes me happy and lifts my spirits: there are some low-cost changes to our platform that could make everyone’s life a lot easier, and all you need is to send me an email or IRC ping. The XULRunner team is not “less that one developer”, but it is dozens of Mozilla Corp. employees, and hundreds or even thousands of developers working on the entire Mozilla platform. That I’m the only Mozilla Corporation employee working on nsXULStub.cpp is irrelevant, and a distraction from the accomplishments that we have all made together.

Each year Seneca college (Toronto) hosts FSOSS: the free software & open source symposium. There will be quite a few Mozillians at this year’s conference: Neil Deakin and I are both giving tutorials, on XUL and XULRunner respectively. Eric Shepherd will be speaking on developer documentation, and Mike Shaver will be giving the opening keynote.

If you are in Northern America and have wanted to go to a conference but the big conferences were either too expensive (OSCON) or far away (FOSDEM), I heartily recommend this one: it’s inexpensive ($20-30), Toronto isn’t that hard to get to, and you’ll get a chance to meet some great people.

Have you ever crashed Firefox? We’re trying to make that as rare as possible, and we have a new tool under development to make that possible. Google and Mozilla are working in cooperation to replace the closed-source Talkback crash reporter with an open-source crash and defect reporting mechanism, called Airbag. Check it out!

I am excited about this project for several reasons:

• Developers and bug reporters can get immediate crash stack information on the client.
• Firefox and other Mozilla-based applications can combine symbol information from multiple sources, including the XULRunner runtime, application binaries, extensions, plugins, and perhaps even some system libraries.
• It will hopefully allow us to collect stack information from some kinds of runtime assertions, not just crashes.

Airbag itself is just a set of libraries that read symbolic debugging information from binaries, collect crash information on the client, and process the crash information on a server. Mozilla will be working on related projects to integrate the client and server libraries into our applications. I am hoping to have airbag included in XULRunner trunk nightlies within 8 weeks, release and collection infrastructure allowing.

I’ve been busy, but I’ve got some good XULRunner announcements:

• XULRunner 1.8.0.4 Released. Get it while it’s hot, it’s a security/stability update of the developer preview.
• With the XULRunner released, we’ve finally pushed out a Gecko 1.8 release of the Gecko SDK. Thanks for being patient.
• Darin’s machine that was hosting a number of XULRunner examples including MyBrowser and XULMine has died. He sent me the files and I am hosting them on this site for the time being, until the Mozilla Developer Center gets example-hosting capabilities.
• preed has agreed that it would be good to get a release of XULRunner 1.8.1 out, and he’s going to try to arrange for some build-team time to get tinderboxes set up for that. The schedule is going to be “sometime after Firefox 2”, but it will happen. Continued thanks to the build team for their efforts, and welcome TR to the vortex!
• Javier and I have finally fixed a couple bugs that make it possible to do universal builds of XULRunner. I expect that, build-vortex willing, XULRunner 1.8.0.7 will be a universal release, as well as the 1.8.1 release.

I’ll be giving a talk on XULRunner at the upcoming O’Reilly Open Source Convention (OSCON) on Thursday, July 27 from 4:30 to 5:15 p.m. The talk will include a demonstration of XULRunner‘s ability to run web applications and web widgets outside of the traditional browser framework, as well as demonstrate deployment techniques for rich-client applications. The talk is similar to the one I gave at XTech, but I have refined it a bit and XULRunner has continued to become more complete in the meantime, so some of the demonstrations will hopefully be more polished and complete.

If you’re still just thinking about coming to OSCON, Myk Melez will be giving a talk on Microsummaries in Firefox, Mitchell Baker will be on a panel discussing open source projects and money, and Mark Hammond will be presenting on Python in Mozilla. Mozillafolk will be attending; there will be a BOF, a booth, a Firefox Flicks screening, and other events. Come and meet Mozillians and learn more about the project!

At XTech, I demonstrated a prototype “webrunner” build on XULRunner. It’s messy code, because we don’t (yet) have a builtin way for a web application to say “this link is an external link that should be opened in the default browser”… so I hacked a greasemonkey-like script to do that. Somebody actually wanted to see my code, so I have posted it in my SVN repository:

GMail in its own process
georgenava.com outliner demo in its own process

The Firefox-on-XULRunner build system is basically in place now: it can produce working builds on Windows and Linux with a couple special configure flags. I even have a set of changes that allow it to be built on tinderbox. Get your hot-off-the-press Windows build here! Note, this was built with MSVC7.1 and you’ll need to already have the runtime libs on your system.

I won’t post Linux builds because my Linux box is x86_64 and is totally hacked up anyway.

Part of the XULRunner planning is not only to release builds of the XULRunner runtime platform, but also to produce and release a set of developer tools, which for lack of a better name I have been calling the XULRunner SDK, or XDK for short.

Several characteristics distinguish the XULRunner SDK from the currently released Mozilla SDK packages: (more…)

IBM today released the first version of their AJAX Toolkit Framework, a plugin for the Eclipse IDE that allows developers to develop, inspect, and debug web applications. What is very cool about this project is that they are using XULRunner (with its builtin JavaXPCOM embedding support) to drive the web technologies.

I suppose that I’ll need to get to work creating user-friendly installers for XULRunner now. The current instructions instruct users to install XULRunner using the command line --register-global command-line flag, which isn’t very user-friendly.
Screenshots courtesy of Javier Pedemonte: