“The Next Bang” prophecy fulfilled.
The cover story last September (Issue 77) was “The Next Bang: The Explosive Combination of Embedded Linux, XML and Instant Messaging”. A story with a title like that carries the burden of prophecy, so a follow up is obviously in order at some point.
As I write this, now is last November, and the buzz is still bigger than the bang, though no less portentous. Linux Journal gave Jabber—the XML-based, open-source instant messaging system—an Editor's Choice Award in the Communications Tool category. Linux Magazine named it Best Collaboration Tool. Tim O'Reilly talked up Jabber at the O'Reilly Open Source Convention and has since joined the Jabber.com board of directors. (Disclaimer: I'm on the Jabber.com advisory board, which involves equity in the company.)
Jabber.com has partnering and other kinds of deals going with VA Linux, Red Hat, Collab.net, Diamond Technology Partners and other parties. The VA Linux agreement, for example, will work Jabber instant messaging into SourceForge, as well as the Open Source Developers Network (and its various sites).
But the first place Jabber is showing up in the embedded “space” is a small one, thanks to its adoption by Transvirtual's PocketLinux as an XML transport between handheld devices. Before getting into that development, let's take a closer look at Jabber's own progress.
Jabber is fundamentally about server software and is maturing rapidly. Jabber.org has released version 1.2, which Jabber creator Jeremie Miller calls “a generational leap forward in server technology and architecture”. The big changes, he writes, are “component-based architecture and...pervasive flexibility and extensibility.” Here are some of the details:
The new architecture is very characteristic of a typical component architecture. The core components are a client socket manager, server socket manager, session manager, file-based xdb (Jabber's interface to the file system and to databases such as LDAP—Ed.) and dns resolver. Each component is loaded and managed by the Jabber dæmon process, jabberd. Additional components can be added easily, such as protocol transports, services, agents and other utilities (note that these are not included in the core server release). These components are all assembled together by a master configuration file that acts almost like a programming environment, enabling the administrator to assemble and structure the components in a wide variety of ways. The new architecture is also very networkable, allowing any component to be removed and placed elsewhere on the network, duplicated or shared by a variety of components. This new architecture is designed to allow the server to be molded into a variety of environments and be used all the way from devices to large server farms. It's important to note that this architecture has been designed from the ground up to support operation in a server farm, with work progressing on a poll-based socket manager (tested up to 40,000 concurrent active users already). Also related is work being done on a simple name-based hashing extension to distribute load for a single domain across multiple components or servers.
He continues:
Through the component architecture, any piece of the server can be transparently replaced by an external script or application. The jabberd process knows how to execute components as well as communicate to components via a tcp socket. With only a small Perl or Python script, or a simple Java application, additional functionality can be added to the server just about as easily as a web server can be extended via the CGI interface. All data access (vCard, roster, off line messages, etc.) can be handled by any component and authentication and registration requests can be redirected anywhere.
six for Windows
four for Linux
one for Newton
one for Mozilla
one for Mac
one for Java
As of October 12, 2000, Jabber.com counted 50 active, open-source projects, with 17 already available. Subprojects included Palm, Java and HTTP clients, plus integration of the Jabber server with Sun's Java 2 Platform Enterprise Edition (J2EE) and Sun's iPlanet LDAP directory server.
But what makes Jabber most interesting, from an embedded perspective, is outside the realm of what we might call “classical” instant messaging. This is because Jabber may be best conceived not just as an “instant messaging system” but as a very efficient and scalable way to transport XML streams in real time. In the words of Andre Durand, Jabber.com founder and general manager, Jabber is “an XML router”.
The first company to put this aspect to use is Transvirtual (see Doc's interview with Tony Fader and Paul Fisher of Transvirtual in the January 2001 issue of Embedded Linux Journal), which has been active in the embedded space since it was founded in 1996. They recently developed the PocketLinux development platform, which is designed for building communications infrastructure for transporting and displaying XML documents, primarily on handheld devices. Tony Fader, Transvirtual's VP marketing, says PocketLinux is an “end-to-end system platform that allows you to write your applications in XML and Java and then run them on Linux”. It includes a small-device implementation of the Linux kernel, plus Kaffe—Transvirtual's open-source Java implementation.
Kaffe is “really a superset of the Java specification”, Fader says. “There are extensions to our abstract windowing toolkit. We have an integrated frame-buffer graphics library. We have extensions for supporting XML. We have extensions down into Linux for implementing things like video for Linux and MP3-playing and so forth.”
What Transvirtual found in Jabber was a perfect way to transport XML streams to and from small devices, especially upcoming generations of handhelds, including PDAs and mobile phones. The two development teams met at last August's LinuxWorld Expo, where the Transvirtual guys were drawing mobs of attendees by showing off PocketLinux on VTech's Helio PDA.
Says Fader, “The Jabber guys kind of tracked us down at LinuxWorld and requested that we investigate working together. We were swamped, so we didn't get around to looking at their technology until later. When we did, we found it to be a perfect match. Their technology really meshes well with what we're doing. There are other messaging systems, but they're not XML-based, or they aren't designed for instant messaging per se.”
The result is less a codevelopment effort than a vast expansion in the scope of web development. Standard PDA applications—calendar, address book, notes, task lists—no longer need to care mostly about syncing up with a PC. “The idea...is to make the apps network-aware”, says Transvirtual senior developer Paul Fisher. “We're moving to a world where you're constantly connected. That's a good thing. If people need to reach you, they can. If you need to reach somebody else, you can. Applications will presume that you're already connected to the Internet. So they can always grab or send the data they need.”
The application would essentially be written for the Jabber server, so fresh information (a change in the calendar, for example) can be pushed down to PDAs, desktops and cell phones over XML streams. The applications themselves wouldn't be locked into a hardware platform, bypassing the familiar morass of incompatibilities between all these devices. Communicating and rendering XML data are about the only requirements.
At this writing, the Transvirtual and Jabber people have collaborated on one demonstration project so far. It involves two Compaq iPAQs equipped with 802.11 wireless LAN cards, exchanging XML streams using Jabber as the transport.
“It's still early”, Fader says. “I would like to point out that not one medical app has been written for this framework yet, not one logistics app, not one shipping, manufacturing or warehousing app. The developmental paradigm here is to be able to write an application that can be fitted to any number of different sectors using this license-free framework, and this framework allows for the rapid development of cross-platform applications. It's extraordinarily compelling.”
