Adblock Plus and (a little) more
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.
Special-purpose platform
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.
Comment [12]
Commenting is closed for this article.
Neil Rashbrook · 2010-07-04 14:31 · #
FTP upload has apparently been around since bug 18977 added it 10 years ago, although it took another 4 years before bug 24867 got around to adding some UI for it.
Reply from Wladimir Palant:
I think you are right, my mistake here – I was under the impression that the protocol implementation didn’t support upload. Bad example then.
pc1oad1etter · 2010-07-04 21:16 · #
The attribute/property thing was one of the earliest quirks that tripped me up. Even after a year or two developing with it, and thinking that I somewhat understood how it worked, I still remember trying every permutation I could think of to properly create, set, unset values in some widget.
My general thinking now is that you set the attribute before you add it to the document, and the value afterwards.*
* Except when you don’t.
Colby Russell · 2010-07-04 21:44 · #
pc1oad1etter, since most of the JS-property-to-DOM-attribute sugar is implemented via XBL setters, you need to wait until that element has been added to the document, the document is open, and the element isn’t essentially “display: none;”.
shmerl · 2010-07-05 03:13 · #
Is XULRunner mature enough for competitive rich interfaces? For example Flex provides very dynamic GUI out of the box. (I.e. one can implement a GUI in Flex/ActionScript, and backend in a language of choice – C++, Java etc.). Same is possible with XULRunner in theory (GUI in XUL/JavaScript, and backend in C++/Java etc. through XPCOM). But it seems that sole focus on Firefox limited the “out of the box” GUI capabilites of XULRunner comparing to other GUI XML based approaches (Qt has another for example). Or this impression is not correct?
Reply from Wladimir Palant:
I’m not sure what kind of “out of the box capabilities” you expect. Generally I consider UI widgets to be an area where XULRunner is pretty well developed. You can have a look at https://developer.mozilla.org/en/XUL_Reference – it even has widgets like datepicker/colorpicker. The way I remember other UI libraries, that’s pretty much how far you go as built-in widgets go. But I don’t know Flex of course.
FlockFan · 2010-07-05 04:29 · #
Many of the bullet points have already been solved at least part way; .xulapp files that consist of the application in a zip file is known to exist and documented at https://developer.mozilla.org/en/XUL_Application_Packaging Installing and removal uses —install-app and related command line arguments, and finding the version depends on /etc/gre.d.
Actually, writing a browser is one of the worst possible things you could be using XULRunner for – that puts you in direct competition with your platform vendor, and you need good relations with them to get your patches upstream. Ask Flock about it sometime.
Js-ctypes isn’t the silver bullet it’s heralded to be; you still need to know what platform you are running on, since the Windows APIs will not be available on a Mac. Since there are no useful built-in bindings just yet, you will also need to write everything yourself. It might make sense to write a wrapper shared library with C-style exports and tie that into js-ctypes, though – but at that point you might as well have written a XPCOM component, which has the benefit of being able to use the rest of the platform as appropriate.
At this point, using XULRunner for anything but toy projects is probably a bad idea – the platform vendor does not want to be one, and has just thrown their policy on API stability right out the window. It seems that the options for embedding support – a different, but closely related topic – do not even consider binary compatibility at all. Also see the persistent second-class treatment of PyXPCOM despite the fact that somebody had a vested interest in maintaining it – followed right by the various efforts to make APIs tie right into the JSAPI instead of improving XPIDL.
Reply from Wladimir Palant:
Interesting – I never heard about the -install-app flag before, probably a sign of it being very popular :). It is somewhat useless without a working mechanism to deploy/update XULRunner (other than on Linux).
Upstreaming patches is always very problematic, that’s probably what my next article is going to talk about. I doubt that Flock had more problems there than anybody else. Anyway, I mentioned building a browser from a technical point of view – not a political one.
Sure, js-ctypes are only a partial solution, they won’t eliminate the necessity to write platform-dependent code – yet they make accessing OS libraries a lot easier. Particularly applications that only need to access a few OS functions will profit, both because C++ code becomes unnecessary and because the application no longer needs to be compiled on all platforms.
PyXPCOM is unfortunately something that is rather complex yet not necessary for Firefox. And you are right of course – Mozilla doesn’t act as a platform vendor here.
pc1oad1etter · 2010-07-05 18:20 · #
re: —install-app, as best I can tell, that’s necessary in Mac OS X (or maybe it just does the heavy lifting of putting the files in the bundle properly, i don’t know). but i haven’t had to use it on Windows.
pd · 2010-07-05 18:26 · #
Poor XULrunner: almost a runtime but not really; Almost a GUI tool set but not really; Almost a write-once, deploy-many cross platform tool but not really. It must feel unloved.
In terms of OS integration, nothing beats XULrunner. GTK looks good on Windows but not great. Java applications look and behave terribly in general on any platform. .Net just adds yet another API layer to the already bloated set of Windows stacks. If only there was an organisation out there that would support XULrunner’s long-term evolution.
Most of those dot points do not seem insurmountable. Maybe if Mozilla cared more they could show enough leadership to generate a community behind XULrunner that could improve it substantially. Why has Mozilla never shown even that small level of support for XULrunner?
skierpage · 2010-07-06 06:08 · #
“Four years later there is still no mechanism to share a single XULRunner installation between multiple applications”
Sure there is, just run `firefox -app /path/to/XULapp/application.ini`
I think this has amazing potential, it’s really a shame it hasn’t taken off. Hundreds of millions of people have Firefox. I and others would be far more likely to run Chatzilla/Songbird/InstantBird/etc. if they were smaller 4 MB downloads that shared my Firefox runtime, one that automatically updates and that is already running on my computer.
This would mean app developers are tied to Firefox, but as you point out, XULRunner is almost completely determined by Firefox’s needs anyway :-(
I’ve read some blog posts about Thunderbird and SeaMonkey that suggest devs are considering running them “from Firefox”: IMO the -app switch is the way to do it.
Firefox: the browser that’s also a platform for extensions, for Prism web apps, and for cool standalone applications.
christian louboutin · 2010-07-09 06:29 · #
This is one of the best posts that I’ve ever seen; you may include some more ideas in the same theme. I’m still waiting for some interesting thoughts from your side in your next post.
http://www.gavots.com
christian louboutin · 2010-07-10 06:18 · #
Thanks for such a great post and the review, I am totally impressed! Keep stuff like this coming.
sunny · 2010-07-26 12:03 · #
Thank you for your sharing!!
Neil Stansbury · 2010-09-05 14:14 · #
Well having just read this article, I could forgive myself for thinking that the application platform I’ve been using for the past few years called “XULRunner” is different to the one described here.
There is so much in this article that is wrong, inaccurate, and just plain not true it’s scary (and that includes the some of the comments).
A few inaccuracies have been addressed, but on your TCP sockets remark it most certainly is not new:
http://web.archive.org/web/20080111050315/http://www.xulplanet.com/tutorials/mozsdk/serverpush.php
And XulPlanet has been dead for what 3 years maybe?
As for .NET – well this effectively give you the .NET API inside XR apps: http://www.redbacksystems.com/xulu/
As for the comment about toy projects, my current XR app is well over 40,000 lines of JS across multiple extensions – it loads in less than 35 MB RAM and starts almost as quickly as Google Chrome.
I knocked up an Internet TV demo for a client the other day using the XR 2.0 beta, it took me 3 days and that included embedding VLC and writing a Flash player plugin in AS3 from scratch.
Seriously…. what is you want from an internet platform?