The roads I take...

I just read this blog post on extensibility of Safari, Chrome, and Firefox - and it hits a very important point.

Chrome is winning an interesting share of users, Safari wants to do the same, Firefox recently goes out of its way for improvements that make it more alike to the "cool child in the block" that Chrome currently represents. Now, many of the improvements the teams are making are worth to be made by themselves, with our without having competition in that field - I'm not sure all of them are, but that's a topic for other discussions.

What's important is that we look into what makes a difference between Chrome, Safari and Firefox. Now, as I recently posted, the mission is the main philosophical difference. On the side of the product, there is a real difference as well though - even if we'd match Firefox to look, feel and function almost or completely like Chrome (which I'm sure the team are not really targetting, even if they're going a lot of the way in that direction), that would persist - and if it wouldn't, I'd not feel like it would still be right to be called a Mozilla product.

And that difference, the one thing that sets our technology apart from any competition, is the Mozilla platform.

The core of that platform goes back to a decision of a few probably visionary Netscape engineers back in 1998 who found out that the new web renderer they designed for "Netscape 5" in the newly founded Mozilla project was so fast in rendering basic web pages and even form elements that they decided it would make sense to use it even for rendering the browser UI with that renderer - using the same code and definitions on all supported platforms. As HTML didn't have support for all a UI needs and the HTML box model was made for scientific documents and not on-screen design, they created XUL as the markup language the web renderer (Gecko) would use for that UI - but the key was that it was extensible in many ways with very web-like technologies that were - and are - quite easy to learn and use (and IMHO, much of it is even easier than HTML itself, as e.g. <input> has strange syntax there).

The extensibility of that platform and making UI work with web-like technologies made it a no-brainer to support additional modules that could be installed, later called "extensions", nowdays a part of the refined "add-ons" system. As the UI itself is built with the same technologies, that also means those extensions or add-ons can do anything the UI can do or that the application can do - I just recently converted what I previously ran as a full-blown application into a Firefox (and SeaMonkey) add-on (KaiRo.at Mandelbrot), for example.

With the tremendous success of Firefox over the last years, a rather large add-ons ecosystem has formed around exactly that platform that allows any extension the same flexibility as the application itself - and even though generic packaging and installing isn't very well-supported, whole applications are powered by the Mozilla platform or based on Mozilla technologies.

And that is the real strength of Mozilla technology-wise. We have a very powerful platform that allows building extensions to our applications or whole products by themselves (using XULRunner), and all those use "web" or very "web-like" (but IMHO to some part even cleaner) technologies and work on all platform that platform can be compiled on, recently that even can include mobile devices.

The real technology difference of Firefox, Thunderbird, and SeaMonkey to any competition is that extensible and powerful platform. If we want to "win" over any competitor, this is one thing we really need to focus on, this is the ace we need to play. Other might try to match us there, but we have put 10 years of the work of great minds into developing that strength, others won't match that easily.

So, let's put this difference to work. Our mission for a better and open Internet and this great platform technology ought to be a game-changer. We need to build on those to succeed. But we can do it. So let's get to work, and let's tell people about it.

This week, I found some more time to hack around on my fun project to do a Mandelbrot set fractal renderer in XULRunner - some of that fun hackery done on the N810, some on my desktop, finally some on my laptop, and now those sources create a really usable application.
The only thing holding me back from doing a downloadable "(pre)release" package of any kind is that it's still somewhat hard to do that for XUL/JS-only XULRunner apps. I'd need to compile my own XULRunner and package it with that or such to get a usable downloadable thing.



What I added this week to bring it over the top was a zoom function that works by dragging the mouse over any piece of a rendered image and a possibility to bookmark locations and call them up again at a later point. With that, one can easily navigate to different places and get pictures like the one above - my laptop calculated and rendered the original 1280x1024 picture in a matter of seconds, with a 1.9.1 XULRunner from some time this weekend, so the same TraceMonkey present in Firefox 3.5.2 to calculate all those iterations, and I did save the contents of the canvas used to paint it as a PNG with the functionality I have in the application. Any quality degradation comes from scaling and converting to JPEG on my web server.

Oh, and there's one more interesting picture I did get out of this work:


(larger sizes linked, original 1280x1024 desktop-wallpaper-ready version available on personal request)

All the fractal pixels in this image come from TraceMonkey's calculation again, of course, but the GIMP helped slightly to finish off this one.

When I opened the source to my Mandelbrot fun project, I did this because I hoped people would look into what TraceMonkey could optimize better there, and because I hoped an open example application helps others base their apps on XULRunner.

Now the second part is a long-term goal that I don't expect will be something that happens soon, but the first point has already been followed: As Boris points out in his comment, he filed two bugs on TraceMonkey, being able to use my code or variations of it as testcases, and there are good chances TraceMonkey will be improved to speed up those cases as well.

Additionally though, Boris pointed out possible ways to improve my code in an earlier post after reading it, and a guy calling himself "prefiks" implemented those ways and a bit more in a patch linked in another comment. When I applied that patch, the numeric algorithm approach with TraceMonkey enabled was sped up by a factor 5 and now I get the base image painted in 1.2 seconds on my machine - and even see updates of the image during drawing, which is what I wanted all along! I also tested it with the XULRunner of Fennec M7 on my N810, and even though it takes a bit over 90 seconds to paint this image, one can watch it build up and so it even feels usable there!

So, opening the source should help TraceMonkey being improved and even helped me making my fun side project more usable. This is the power of keeping the source open, and I hope an encouragement for other people to do the same.

As comments to yesterday's post about TraceMonkey suggested I should show my code so the JIT code could be improved for things like what I'm doing, I decided to go all the way and publish this today.
I just completed putting all my code of this project under the Mozilla tri-license and making it available via both a gitweb interface and for cloning with git clone http://git-public.kairo.at/mandelbrot.git.

That said, a few details about the application itself:

This is a fun side project, its main target is for me to learn XULRunner and improve my skills with the used technologies. Its second target is to recreate an application I had started for my my final paper in school with modern technologies.
The application renders images of the Mandelbrot set fractal, the original application had nice zoom functionality and could even render the very similarly calculated family of Julia set fractals, which are both features I want to add incrementally to this XULRunner-based version as well.

The current versions calls itself "KaiRo.at Mandelbrot 4pre", which probably warrants a short view on the version history: The first version, "RK-Mandelbrot 1.0" was created in Visual Basic 3 during work on that school paper, I incremented the minor version number as I went along with that work, the version I had on a disk coming with the paper was "RK-Mandelbrot 2.0", this or a slight minor update to it was also used during the presentation/exam on that paper. I later updated it to Visual Basic 5 and played with a few features, calling the result "KaiRo-Mandelbrot 3.0", also noting the change from using my initials to the "KaiRo" name for my work. Because of this history, I'm targeting a version number of 4.0 for the XULRunner rewrite, and also using "KaiRo.at" as the vendor name, as that's also what I'm using as my corporation name prefix.

Some comments on the current code:

On the base level, I created a mandelbrot launch script, which tires to find a XULRunner in a few places and uses it to launch the app using the application.ini inside the xulapp directory, which contains files in the usual structure for XULRunner apps.

In the running app (the launch script also launches the error console for debugging), the File menu enables access to drawing the image, saving it (very ugly right now, hardcoding /home/robert/temp/canvas-save.png as the path!) and quitting the app. The Settings enables different settings for maximum number of iterations (I'm using a simple escape time algorithm) and color palettes (which are currently stretched according to the max iterations number; also, I have not ported all palettes I had in the VB version, leaving the non-ported ones in an ugly comment in the JS file). Today, I also added a Debug menu that allows switching TraceMonkey on and off and switching between the slow but nice-looking object-oriented algorithm and the faster but not so pretty numeric algorithm. I also added a label at the bottom of the window that informs about the currently performed action and a rough time measurement when drawing is complete.

The image you'll get with the default settings of max. 500 iterations and my custom "KaiRo.at" color palette looks like this:

Once I can do a zoom function, I hope I can produce more interesting images - I'll publish a number of them in the gallery.

There's a lot that probably can be improved in that app, it's just a fun personal playground, as I said. But if anyone wants to look into what it does and perhaps see how TraceMonkey could perform better on it, feel free to look into it, the source is all open!

As AllPeers, Mark Finkle and Songbird have all posted their wishlists for XULRunner's future, I think it's a good idea to throw mine in, in the light of possible Mozpad acitivities on such items.
Not that this is my personal view as a SeaMonkey and L10n contributor and no common view of the SeaMonkey project or the Mozilla L10n Project (MLP), though I'd guess that some of those items would be on the wishlists of multiple community members in those projects.

• Killing app-specific differences in toolkit:
  Toolkit and other core code still contains app-specific ifdefs in many cases, which block moving the applications to XULRunner. There should be no need for MOZ_PHOENIX, MOZ_THUNDERBIRD, MOZ_SUITE and friends in that code. We came across such problems in printUtils recently, and I'm sure there are still enough others. Efforts like generalizing openURL() are good steps, but actually long overdue.
• More robustness in mozStorage:
  When the topic of moving any code to mozStorage from RDF or Mork backends in SeaMonkey or MailNews comes up, people keep telling me there are so many warnings around how easily things can go wrong with mozStorage/SQLite when it comes to other apps wanting to access our data or even multiple threads accessing the database (see How to corrupt your database). If we want to make mozStorage the general backend for databases in XULRunner, we need to find way so that that developers don't back out because of such fears before even trying to use it.
• Template Query Processor for mozStorage (bug 321172):
  SeaMonkey has a lot of UI that is based on RDF templates. If we should be moving to mozStorage as a backend for much of our data, it would be very helpful to be able to be able to build UI as easily as for RDF, which needs templates to work with mozStorage.
• Pipe-based IPC (bug 68702):
  Invoking external processes and controlling them via stdin/stdout or even named pipes is something that many more XULRunner apps will want in the future. I mostly care for having a good way to integrate EnigMail/OpenPGP into SeaMonkey by default, which needs to call gpg through such a mechanism, but I'm sure there are many other needs for this.
• OpenSync support (bug 303963):
  While the linked bug report is about MailNews and most of the work for this is probably app-specific, it might be a good idea to provide hooks on the platform side to hook into this open, cross-platform data synchronization framework, so it's easy for Mozilla/XULRunner-based apps to use it and provide synchronization with a wide variety of devices and applications.
• Profile management improvements:
  Profile roaming seems to be something that gets requested again and again, but does not work well. The mostly working framework we have for that in SeaMonkey 1.x is broken with toolkit profiles on trunk (bug 378647) and there's no code for doing this with toolkit profiles. I also would love to have profile language selection back if multiple languages are installed for the application (also an xpfe feature not supported by toolkit). Accessing one profile from multiple instances/processes (bug 135137) would probably be nice but is hard to get right.
• L20n (wiki page):
  The localization framework used for Mozilla applications up till now has its merits but also its share of problems. Based on what we know about current localization frameworks, which all have their own big problems, Axel Hecht, the L10n lead of MoCo, has figured out a next-generation L10n framework which he calls "L20n". We really need such an improved framework with one single file format for everything and enough flexibility for complicated languages (those are out there and currently not supported well in any software).
• Language switching in EM (bug 377881):
  Being able to easily install a language pack and switch to using it is good for L10n testers but sometimes also for normal users, esp. in multi-language families and countries. We should not clutter the interface for those users who don't need this, though. To achieve that, we can leave the current way of language handling in Extension Manager, just with small tweaks so that language switching is handled the same way as theme switching.
• Tray icon support (bug 325353):
  The main reason why the so-called "Quicklaunch" feature on Windows has remained popular with our users in the SeaMonkey 1.x product line is that they have a tray icon with a context menu that provides fast access to open browser and mail windows. Additionally, it kept mail libraries loaded and provided information about new mail arriving - and it allowed to close all SeaMonkey windows and still have fast access to the browser, mail and get this mail notification. It would really be nice if we could still provide that functionality with toolkit-based versions of SeaMonkey, but we'd need tray icon support in toolkit for that.
• Splash screen support (bug 329742):
  This might sound like a small thing, but having a splash screen gets branding across, which is why I believe many corporate users of XULRunner will want this, and on laptop machines with slow harddisks, even Firefox takes long to launch, with currently no visual feedback at all to the user that anything is happening.
• KDE integration (bug 140751):
  As a KDE user, like probably half or more of the Linux population, I'd really wish we could integrate more with KDE. We currently are able to fetch file type icons (moz-icon) from GNOME, and system settings also from there, but it doesn't help much when GNOME isn't configured much because I never use it. We've grown to use themes from KDE quite well in default themes, as KDE makes GTK inherit its settings and we inherit them from there, which works interestingly well. It might be worth to investigate how we can pick up other things through such channels, like e.g. default apps for certain MIME types.

I think I have touched my main wishes here, others might still come up to my mind later, but I hope they're only smaller wishes

Our Planet lately has been full of XULRunner talk.
And this is good, as it clearly tells that there's wide support of that technology, and things are moving on in that area. While we unfortunately have not yet reached a point where we can magically deploy a common, shared runtime and this vision will not get a reality in the Gecko 1.9 timeframe, the XULRunner platform is growing, and lots of work is being put into it, by MoCo and lots of outside volunteers. This is a cool, open, cross-platform base to builds applications upon, it will get way better even in the Gecko 1.9 cycle, and it will continue to improve in the future. I'm sure of that.

What we need though, is a stronger community around it - not that we lack people working on it or using it, or knowing its internals and deployment, we just can improve a lot in their communication. This helps "users" of the platform (those building apps based on it) in getting better info about how to achieve what they want to do, it helps people working on the platform in knowing what those "users" need to make working with it even easier - and it helps the platform itself by getting patches into it through this collaboration (hopefully also patches contributed back by the platform users).
Mozpad ("Mozilla Platform Adherents and Developers") is a good idea, and we build upon that idea to get such a community started. I hope though that we will leverage existing Mozilla community infrastructure as much as possible there so that it's as easy as possible for people already in the Mozilla communities to participate there.
Daniel Glazman insists in recent blog articles that we need a real name for this runtime, a logo, images "Built with Xulrunner", more visibility on the web sites, and articles in the press. I must admit that I'm with him on that - though I believe, despite I also have heard of other plans - that we should not pick any new name for that runtime/platform. The current, originally temporary, name of "XULRunner" describes exactly what it is - it runs XUL applications, it consists of everything building up the XUL platform - it basically markets the core technology of our platform, which is probably XUL. The majority of XULRunner builds around what is needed to provide XUL with everything it needs to works as expected, so that name serves very well to tell the message that "if you want to use XUL, you need XULRunner". And then, I think the package already got spread widely enough under that name that we should just stick to it, as changing it would probably trash all publicity it already has in developer communities (which are the target audience of this technology, right?). We really need a logo, and "built with XULRunner" images based on it, though. Maybe a good point for starting off the new community.

The SeaMonkey project got some really positive attribution in that recent platform/XULRunner discussion, by the way: John Lilly counts SeaMonkey among XULRunner/Mozilla-platform apps that are doing amazingly well, Mike Shaver is calling our project an excellent example of contributing to the platform, and talks of our success as a volunteer project: SeaMonkey is a great example of a group within the Mozilla community that has shown leadership and motivation in developing, supporting and marketing a piece of software that doesn’t have any Mozilla Foundation employees tasked directly to help it — though some Employees do indeed work primarily in the context of that product as a personal choice, and that’s a fine thing.
It's really good to hear people talk about SeaMonkey this way, it has been hard work to get here, and lots of people didn't believe we could ever get here when we started off this effort.

Oh, and we surely won't stop to work hard on getting even further along. As you might know, though we are using big pieces of the platform building up XULRunner, we still have major steps ahead to get a "real XULRunner app", the efforts for which we have code-named "suiterunner". The major step in that direction, killing xpfe in favor of toolkit should happen really soon now, and we will continue to adopt new technologies present in XULRunner, replacing old, often badly or non-maintained code in current SeaMonkey - without killing the feel of the suite our users have grown to love.
We will continue to be a good example of a XULRunner user, improving this where we can, as this helps both sides: SeaMonkey is a good testcase of an extensive, non-browser-only app building upon XUL technologies, which helps to improve XULRunner as a platform for such products, while we can get out a platform that serves our suite better.
Because of that, the SeaMonkey project will be proud and glad to be a member and supporter of a stronger XULRunner community, helping to make this Mozilla platform the best comparable product on the market.

A Japanese blogger called "Amigomr" seems to be picking interesting posts from the Mozilla blogoshpere and translating it to Japanese to give us a wider audience in Japan. This is awesome - and something that's probably only possible due to the web and maybe the "Web 2.0" phenomenon.
And now, this blogger asked me if he was allowed to also translate my posts - so if it's easier for you to read my earlier post about The Mozilla Platform, Firefox, and SeaMonkey in Japanese, here is the translated article!

I never thought I'd see my own blog posts in a language I am not nearly able to grasp. Again, thanks, that's just awesome.

The recent discussion of the Mozilla platform is really interesting to read. The arguments go from "we need to be more of a platform" to "needing platform tools is bad", and interestingly, I tend to agree with a real lot of those - as I guess will most active SeaMonkey and general Mozilla contributors.

Sounds strange? Actually, it's easy to explain:

For one thing, there's the Mozilla Manifesto, which, even though only taken into words this year, describes what we in the Mozilla development community have already been working for in recent years and we will continue to go with those principles. In a certain way, it's nothing more than the base Mozilla mission of "preserving choice and innovation on the Internet" which always had been there and will still guide us to the future. Because of those common principles, we have similar visions for the future of the Mozilla project, the browser and the web - those those vision vary in their details, of course. But still, there are strong similarities, so no wonder if we agree in principle in lot of topics on "the platform".

And then, "the platform" is multiple different things, actually. There is the Mozilla application architecture, or XULRunner as a platform to build internet software, usually based on XUL and cross-platform (though Camino doesn't follow that exact path and is still based on that platform). As the platform is "only" the backend for application, it probably receives equal or more work but less publicity than the applications built on top of it. Those applications, most notably Firefox, but also Thunderbird, SeaMonkey or Sunbird, due to the rich extension architecture built into them, are another platform though - it's awesome what interesting work gets done based on that extension platform. And then, the web itself is a platform nowadays, and it gets richer and richer. After all, that's what "Web 2.0" is all about. And our browsers are supporting that web platform through a lot of open standards we implement.

So, if we're talking about "the platform", we're probably taking about different levels of that tiered platform stack all at once. And surely we can improve all those - Gecko 1.9 and upcoming Mozilla2 work is directed at improving all those platforms and lots of work on them is happening as I'm writing this and you are reading this. So, Mozilla will be a better platform and we're all working on that, as we know we want that: a better application platform, a better extension platform, and a better entry door to the open web's platform (no, not a platform for the web, but a client for the web platform - the web will never be tied to us, it's much more the other way round). And yes, as shaver points out, you don't need tools to work with those platforms (I'm doing my work on all those platform levels with a simple text editor) - but of course, there can be tools to ease working with them. Still, using a tool means that you give some control of your work to that tool instead of having every single character of the document in your own hands. And you can keep that full control yourself when building on our platform(s).

The difference in those platforms is that we control both the application and extension platforms in the Mozilla community, we can keep them as open as we want/need to fulfill the Mozilla Manifesto we all believe in, and to preserve choice and innovation on the Internet.
The web as a platform is nothing we have direct control of - after all it's way bigger than our own community, it's actually what we build upon (without the web there would probably be no Mozilla project at all), we are only a part of the ecosystem. And there are other forces at work there, which don't follow the Mozilla Manifesto, some because they want to earn their money in other ways than us, some because they want to create web sites and apps that look cool and work for some group only without caring for a wider audience or free choice of clients. I'm sometimes shivering when I see how many "Web 2.0" services depend on the closed Adobe Flash system, for example - which needs specially crafted, potentially expensive, tools for creating content, and a viewer that is still not available for 64-bit systems or minority platforms such as BeOS, from what I know. There are also lots of sites out there that do browser detection and close out any browsers their creators didn't know, even if they'd work perfectly with their content, and so they are effectively closing out users and, yes, customers.

As Tristan points out, Firefox has helped a lot in making the web better, as a standards-compliant browser with 15% market share gives better reasons for people to create standards-compliant web content. And I'm with him that this market share still needs to increase (not by heavily competing with other standards-compliant browsers though, users of non-compliant clients need to be targeted primarily - and Firefox has the right concepts to serve as vastly improved replacement for IE). Unfortunately, web content creators haven't grown more intelligent with Firefox' rising market share though, and so they're still heavily using browser detection, often wrongly looking for "Firefox" in the UA string instead of realizing that Gecko is Gecko and so SeaMonkey, Minefield and other non-Firefox-branded Gecko browser users are often closed out unnecessarily.

And where does SeaMonkey fit into all that "platform" talk? Naturally, we fully support growth of all those platforms. Of course, as a consumer of the application platform, we want to see a good toolkit - and we're seeing our product as a good example and testcase for a non-browser-only app built on this platform, often raising problems there that wouldn't be seen by having only Firefox as a consumer. We are also trying to be a good extension platform, vastly improving this by moving to the new extension management infrastructure of toolkit with our next major release. And, of course, with a heavier orientation on power users, experts and web developers, we're standing united with Firefox in supporting an open web platform, hoping to fill a market niche that our trimmed-down browser-only brother may not reach that well with providing our integrated solution and providing more options directly in the default UI.

I think, in the big picture, that we are all big supporters of all those tiers of "the platform", even though I guess, most of us want their respective part of it to get the most attention. In the end, we all want all parts of it to thrive, and I also see that happen as we work on them together - now and in the future.