RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Longhorn and Mozilla: Birds of a Feather : Page 2

Windows Longhorn is a demonstrably powerful and ambitious concept, but the architectural principles are hardly new. From 10,000 feet, Mozilla's architecture looks remarkably similar.

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<Button>Press Me</Button>
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.

   <window xmlns="http://www.mozilla.org/
       Some Text<button>Press Me</button>
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();
   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?" +
   transport = transport.createInstance();
   transport = transport.QueryInterface(
   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.

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.

Nigel McFarlane is a freelance science and technology writer, analyst and programmer. His most recent work is "Rapid Application Development with Mozilla" (Prentice Hall PTR, Nov 2003). Reach him by e-mail at nrm@kingtide.com.au.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date