Longhorn and Mozilla: Birds of a Feather

oftware technology goes forward in fits and starts. Bigger advances can cause plenty of information indigestion for technologists. At each leap, a new understanding gap opens up. Such a gap takes learning effort to close. Windows Longhorn is a big advancement for Microsoft, and the understanding gap created is proportionally large. Take heart, there’s little that’s truly new under the sun. A look at Mozilla technology shows that this road is already laid out. Don’t believe me? Read on.

Mozilla: An Application Platform?
Mozilla is the technology behind the Netscape Navigator 6.x and 7.x Web browser. Although Microsoft beat Netscape to a pulp in the “browser wars,” the Mozilla technology underneath didn’t quite die. Instead, it mutated into an application platform. Mozilla applications such as the Mozilla browser are built on top of this new Mozilla Platform. The browser application is not important for this discussion, but what lies underneath it is.

This platform is a fairly generic group of technologies implemented as a single executable and a set of dynamic link libraries. You can use the executable as a starting point for a wide range of software applications. For example, you can easily create a set of interpreted files that display a window just like any Visual Basic, Java or Tcl/Tk program. Sometimes the resemblance is perfect. Companies are already building on and using the Mozilla platform for commercial applications?some of which run outside the Mozilla browser itself. Examples are tools such as ActiveState’s Komodo IDE, Pearson Education’s Longman dictionary-on-CD software, and Crocodile Clips’ e-learning tools.

In the tradition of modern software tools, the Mozilla Platform isn’t small, either. It contains about three thousand object-interface combinations, and half a dozen different integration technologies. The source code for the platform is one of the biggest Open Source projects in the world (Open Office and the GNOME Desktop Suite are larger). It’s far bigger than the Linux kernel source. It’s far bigger than Perl.

Mozilla Platform Redux
Mozilla has a complete, separate, and enhanced implementation of Microsoft’s COM, called XPCOM. XPCOM has its own QueryInterface() method, which acts just like the equivalent method in traditional COM. The 3000 object-interface combinations are due to over a thousand XPCOM components, most of which are bundled with the platform in compiled form.

To support these components, the basic infrastructure of the platform consists of several pieces:

  • A fancy application-level GUI display system called Gecko. This is a layout and rendering engine.
  • A very high-level networking library, called Necko
  • Comprehensive XML support for various standards like XHTML, MathML, SVG, RDF, SOAP, WSDL, and UDDI. Additional support for several unique XML dialects, particularly XUL and XBL, which are used to define GUIs.

Mozilla binds these pieces together in several ways:

  • By use of XPCOM and JavaScript at the object/code level
  • Using data models expressed as XML RDF and by systems that exploit these models at the XML level
  • By programmers using XUL and XBL as a starting and integration point for applications..

Software Architecture Reflects Hardware Architecture
Software architecture usually reflects hardware architecture, and Windows is no exception. The big elements of a desktop computer are still screen, network and disk. In the past, Microsoft Windows bound all these elements together using the Win32 API, with GDI and NTFS acting as noteworthy sub-components. Of course, there have been many enhancements on that basic structure, like COM/DCOM and DirectX.

Now, with the Longhorn release, Microsoft is finally replacing the integrated Win32 model with separate pieces:

  • Avalon (screen layout and rendering)
  • Indigo (high level networking)
  • WinFS (high-level disk content management)

This new three-way model clearly reflects the hardware.

Windows binds these pieces together in several ways:

  • Via .NET, the COM replacement that competes with Java at the object/code level;
  • Via data models expressed as XML Schema and by systems that exploit those models at the XML level, and by programmers using XAML as a starting point and integration point for applications.

If these lists and the previous set sound repetitious, they should. Avalon is architecturally equivalent to Mozilla’s Gecko. Indigo is architecturally equivalent to Mozilla’s Necko. Longhorn XAML and Mozilla XUL are nearly identical at first glance.

Still, they’re not quite identical. WinFS has no exact Mozilla equivalent. A messy aggregate of local Web caches and pluggable search engines is the best approximation Mozilla has to offer.

Similarity exists elsewhere, too. On the object integration side, Mozilla doesn’t support .NET but XPCOM is a simpler equivalent. On the XML integration side, Mozilla has RDF and overlay systems that perform some of the roles that that Longhorn’s use of XML Schema performs.

The details and edges of these gross comparisons are a bit ragged, but overall the similarities are real.

Similarities Extend to Code
So Longhorn and Mozilla have architectural similarities?so what? As developers, the more important question is whether the software development processes for the two platforms is also alike. Yes, they are. The following code shows a simple Longhorn XAML-based application that creates a window containing some text and a button.

               Some Text        

This XML document is a finished, if simplistic, application containing proprietary tags that specify or modify the layout of the window. Here’s the same application written in Mozilla’s XUL.

               Some Text        

As you can see, the namespaces and tag names differ, but otherwise, the code listings for the two applications are essentially identical. The resulting applications behave identically, too?right down to the multi-line reflow that occurs when users resize the application windows using the mouse. There are some differences. Longhorn currently uses a compiler. Mozilla uses an interpreter.

The development similarities aren’t restricted to XML markup. Let’s see what happens when scripting up network code for Indigo or Necko. The following code fragment contains Microsoft JScript.NET code that submits some test data via a SOAP request.

Author’s Note: Don’t try this at home without a safety net?the current Longhorn release is very pre-beta.

   import System.MessageBus;      var args, server, method, port, channel;      args    = { data : "Test Data"; }   server  = new Uri("http://saturn/test");   method  = new Uri("http://saturn/test/test-call", args);      port    = new Port();   port.Open();   channel = port.CreateSendChannel(server);      channel.send(method); // go.

The preceding code excludes the plumbing required to wire it up as a XAML event handler. Note that the commands are very high-level networking primitives?there’s no mention of TCP/IP or MIME once. It hides the SOAP plumbing too; there’s no string-ified XML content.

Now look at the equivalent Necko code. Mozilla uses the SOAPCall object instead.

   var args, server, method, soapcall, soapargs = [];      args   = { data : "Test Data"; };   server = "http://saturn/test";   method = "/test-call";      for (var i in args)     soapargs.push(new SOAPParameter(i, args[i]));      soapcall  = new SOAPCall();   soapcall.transportURI = server;   soapcall.actionURI = method;      // various literal arguments to encode() provide the default case   soapcall.encode(0, method, null, 0, [], soapargs.length, soapargs);      soapcall.invoke(); // go.   

The for loop in the Necko case creates a special SOAP object. This step is automated in the Indigo case because SOAP is its default message syntax, whereas HTTP is Mozilla’s nearest thing to a default message syntax.

Both code fragments process the same data, in the same way. Both use a channel object but that channel is not obvious in the Mozilla case. This is mostly because of the opposite software development processes used by Microsoft and Mozilla. Proprietary Longhorn is designed but not fully implemented; the Open Source Mozilla Platform is implemented but not fully designed. You can see a hint of the channel in the setting of the transportURI property?every channel must have a transport to do the dirty work of sending the message.

Equally easily, you could acquire the Mozilla transport component via XPCOM. After all, the Microsoft case acquires components from .NET with the import System.MessageBus line. The following code fragment shows how to get a Necko transport directly from XPCOM:

   // existing array of XPCOM Contract IDs   const Cc = Components.classes;       // existing array of XPCOM Interface IDs   const Ci = Components.interfaces;    var result = {};   var soapcall = ... // much like the preceding example.      var transport =    Cc["@mozilla.org/xmlextras/soap/transport;1?" +      "protocol=http"];   transport = transport.createInstance();   transport = transport.QueryInterface(      Ci.nsISOAPTransport);      transport.syncCall(soapcall, result); // go

Strings starting with @mozilla.org are XPCOM equivalents to COM component names such as Word.Application. You can see XPCOM’s QueryInterface() method at work in the next to last line of code, used just like ordinary COM. In other words, you can apply the simple COM techniques you know from Windows programming directly to XPCOM programming. The cost is that in some cases you’ll have to learn new names. Acquiring components from Java is just as simple. For example, you can call static class methods directly from JavaScript.

   java.lang.System.out.print("whatever");

Tools and Environments Have Different Audiences
The examples in this article are necessarily simplistic. Longhorn is a much bigger and more extensive technology than Mozilla. The similarities fail on many small points of syntax, and on many fundamental integration issues. Not least of these is the vector-based rendering engine underneath Avalon, which is far more extensive and flexible than the raster-based one inside Mozilla. Similar arguments apply to Indigo/Necko. The buckets of human labour thrown at Longhorn are compressed into a short timeframe, whereas Mozilla’s progress is slow but sure. You could die waiting for vector-rendered Mozilla. From a distribution point of view, Mozilla is bundled with Linux but not Windows. That makes it an optional extra for Windows programmers, and not something that automatically supports latest operating system features.

On the other hand, Mozilla applications are portable across Windows, Linux, Macintosh, and most variants of UNIX, whereas Longhorn is not. Mozilla is also extensively production tested and in final release. If you just need a tool rather than a new world religion, Mozilla scores on that front. A discrete tool is also less likely to cause catastrophic network failure than an extensively integrated computing platform.

Microsoft has no monopoly on Longhorn features. For example Avalon’s vector rendering engine is neither unique nor even innovative. Technologies like Flash, Shockwave, PDF, and PostScript all use vector engines today. In fact, all platforms already perform vector processing for restricted tasks such as rendering modern fonts. XAML isn’t a new idea either. Announcements of XML interfaces for various technologies have already begun, and are only likely to increase. For example, the Laszlo Presentation Server provides an XML interface to vector-graphics based Flash. Failing that, the XML Namespace standard already says that HTML and SVG can be combined in one document; therefore, it’s only a matter of time before existing SVG engines support HTML or XAML/XUL as well.

You Can Get Started Today!
Microsoft’s Longhorn release is of major significance because of its size, closely integrated features, extensively researched design, and the existing desktop dominance of Windows. You don’t, however, have to take the pain of learning it all at once. There’s similar technology available already, most obviously in the Mozilla Platform, but elsewhere too if you hunt around. The technology in Longhorn is fancy but not necessarily new. It’s the embodiment of modern software architectural and development trends rather than a shock announcement. It is true, though, that XML literacy is an absolute must for developers of the future. Welcome to the bold new world of declarative XML application development.

Share the Post:
Share on facebook
Share on twitter
Share on linkedin

Overview

Recent Articles: