XULRunner in large projects, part 2: Why XULRunner isn't like Java · 2010-07-04 12:53 by Wladimir Palant
When talking about runtimes people often expect XULRunner to be something like Java. Sometimes people will also mention .NET — if you are one of them feel free to replace the word “Java” but “.NET” everywhere in this article, it shouldn’t affect the meaning in any way. Fact is, XULRunner is very different from Java and I will try to explain why.
No shared runtime
Originally there was talk about providing XULRunner as a shared runtime. The idea was that the user would only need to install XULRunner once and run different applications on top of it — much like it works with Java. Four years later there is still no mechanism to share a single XULRunner installation between multiple applications (Linux distributions are an exception here). And frankly, I don’t expect one to come up. Here some thoughts on what is required to turn XULRunner into a real shared runtime:
- Create an installation/update mechanism for XULRunner that works independently of applications.
- Create a packaging format for applications similar to the XPI format for extensions.
- Add a simple mechanism to install applications into a runtime, ideally also a similar way to remove them.
- Find a way to deal with applications that are incompatible with the current runtime, probably install a second runtime automatically.
- Decide what to do if a security update is necessary for a runtime but some application isn’t compatible with it.
- Somehow make sure not to leave outdated runtimes on the computer (e.g. only keep runtime versions that are still supported with security updates).
If one starts thinking about how all this should be implemented it becomes clear that we are talking about a major effort. From what I’ve heard, Mozilla isn’t very interested in investing that amount of time into XULRunner because it won’t benefit Firefox directly. Rather there is hope that some other vendor of XULRunner-based applications will do it. But realistically speaking — why should they? It is much easier to package a private XULRunner copy with their installer.
There is one more issue that makes the idea of shared XULRunner instances unrealistic. From what I know, no larger application uses XULRunner as it is provided by Mozilla. Instead, these applications always apply own patches to XULRunner. This isn’t very surprising given that Mozilla is mostly looking at Firefox when deciding when/how to fix issues. Other applications have different priorities and different schedules however, e.g. it is often necessary to apply a patch to a stable XULRunner branch that Mozilla only accepted for the trunk.
Which brings us to the next point: XULRunner isn’t a general-purpose platform, its main purpose always was and stays Firefox. This means that XULRunner’s capabilities are very well-developed in the areas that Firefox needs, yet they are at best rudimentary in areas that Firefox doesn’t need. For example, XULRunner has generally excellent networking capabilities which is perfect for applications that communicate with the Internet a lot. Yet functionality like TCP server sockets or
FTP uploads is relatively new. And there is no built-in component for UDP communication other than DNS. One would think that all these capabilities are required for a complete platform, yet creating a complete platform was never the goal during XULRunner development.
What does this mean for you? If the application you are developing is a browser — great, XULRunner will be perfect for you. If however you are developing something significantly different you should expect that some required capabilities will be missing. You can create your own components for these of course. However, you will often need C++ code then meaning that you have to make your own thoughts about cross-platform support. In this context js-ctypes is certainly something to look forward to, it might reduce the need for custom C++ code significantly.
Grown, not designed
The development of the platform that we can use with XULRunner started 13 years ago. During all that time it was growing “naturally”, depending on what capability was needed right now. There was little global oversight and platform consistency was certainly not a priority. This is the reason why, when converting between charsets, you have the choice between nsIUTF8ConverterService and nsIScriptableUnicodeConverter (hint: you should usually use the latter). Why for some notifications you register with nsIObserverService but use nsIWindowWatcher for others. Why some XUL widgets really aren’t good for keyboard navigation. Why sometimes you can use a property of a XUL widget while other times you can only set an attribute.
The good news: things are certainly improving and the platform is becoming more consistent. The bad news: things probably aren’t improving fast enough for you. So you will certainly hit the one or other unexpected issue. And then you will hopefully have the time to fix it so that other people no longer have to spend their time on it. Yes, Mozilla is a community project and the best way to get something fixed is fixing it.
Commenting is closed for this article.