The universal client

Although there are lots of ways to build server applications, most developers identify themselves with Java, LAMP (Linux, Apache, MySQL, Perl/Python/PHP), or Windows. Thanks to XML Web services, these Balkan states are now united to a remarkable degree. There are still a few wrinkles, but the interoperability of SOAP stacks is mostly a done deal. When I look at the emerging cloud of services, I see both healthy diversity and reassuring uniformity.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

I can't say the same for the client landscape, though. There have never been so many horses in the race. Java is exciting again, with Cocoa support on the Mac and with Eclipse's SWT (Standard Widget Toolkit) fueling a renaissance of cross-platform client apps that sport a native look and feel. The .Net Framework's WinForms classes are coming of age, too, powering a new generation of Windows GUI applications that gracefully connect to the cloud.

The Macromedia drumbeat continues, with Flash MX attacking the presentation tier and the forthcoming Macromedia Central aiming to jump-start a marketplace for rich Internet applications. Over at the Open Source Applications Foundation, a bold experiment is under way to prove that a scriptng language (Python) bound to a cross-platform GUI library (wxWindows) can deliver a major-league fat-client application. There are the XML-based mobile desktops from the likes of Altio, Digital Harbor, FourBit, and Droplet. Virtualization (VMWare, Connectix) and remote access are hotter than ever.

Then there's the original universal client, the browser. Even as the AOL/Microsoft deal seems ready to lock the barn door and throw away the key, I'm seeing evidence that the old nag can still run. Following a talk for which I prepared a browser-driven slide show, I did some R&D to find out how the XML content of my slides might be further exploited. The result was a tiny search engine implemented entirely in the browser (see http://weblog.infoworld.com/udell/misc/oscom/search.html), using XPath and XSLT (eXtensible Style Language Transformation).

I got it working in Microsoft Internet Explorer, but suggested on my Weblog that it was just a Microsoft-only parlor trick. Not so. Brendan Eich, chief architect at mozilla.org and the creator of JavaScript, pointed me to the relevant documentation and I soon had the same app working in Mozilla Firebird -- on Windows, Linux, and Mac OS X. Across all these and Internet Explorer 6, it makes effective use of techniques whose universality has long been problematic: CSS (Cascading Style Sheets) for styling, JavaScript DOM (Document Object Model) manipulation for dynamic effects. Don't count Apple's Safari out, by the way. Its honcho, Dave Hyatt, is a Mozilla stalwart. And though he chose the KHTML rendering engine over Mozilla's Gecko, the lines of communication are open. Hyatt recently asked, on his Weblog, which major new W3C technology Safari should next tackle. XLST was a leading contender, and Axel Hecht -- who put the TransforMiiX XSLT processor into Mozilla -- offered sage advice from the trenches.

The game of Web services is played by passing around XML documents. Office 2003 will be the superior technology for writing/editing (InfoPath) and analyzing (Excel) such documents, but in many cases users will be searching, viewing, tweaking, approving, and routing. It's a huge win if we can use Web standards to do these things in a lightweight, cross-browser, cross-platform way. We've waited so long for this moment to come. AOL, please don't screw it up. If you don't get why this matters, turn Mozilla over to an organization that does.