Tangled in the Threads

Jon Udell, June 21, 2000

What's the next Internet client?

Everybody's chasing the same dream: real GUI apps that inhabit the Net, not just your PC

Late last year, a report on the popularity of various scripting tools noted that ASP had made dramatic gains. That didn't make much sense to me. I knew that ASP was popular, but I felt that PHP was probably growing as fast, or faster. Why the sudden ASP surge? Then it clicked. This report was based on a scan of USENET newsgroups for terms like ASP, PHP, Perl, and Python. But ASP is an overloaded term. It wasn't Active Server Pages that was creating this new buzz. It was Application Service Provider.

Ever since the Web redefined applications as network services, we've been waiting for the other shoe to drop. The first-generation browser makes a terrific universal client. That's why today's Web can support a range of application-like services such as purchasing, calendaring, group messaging, airline/hotel reservations, and trading. And it's why ASPs are now able to build businesses around the delivery of these kinds of applications. But the first-generation Web client can't handle meat and potatoes applications, such as spreadsheets and word-processors, in a way that preserves the Web's compelling virtue: anywhere, anytime access with no need to install, configure, or update software.

As we try to figure out what Web applications (or weblications) ought to be, we're like the proverbial blind men feeling the elephant. Here are some of the forms that we can discern:

• Java applets. In theory Java was the right solution: a portable, and mobile, GUI. In practice, things haven't worked out that way, at least not yet.

• Dynamic HTML. In an earlier column, The Future of the Programmable Browser, I noted that DHTML is starting to be able to support lightweight, scripted, Web-style alternatives to "real" GUI apps such as spreadsheets. Doing that in a portable (i.e, cross-browser) fashion is, however, a major problem.

• Remote display, remote control. X Windows had the right idea, and was many years ahead of the curve. The problem here is that the apps most people want to run aren't X apps, they're Windows apps. Remote display/control technology can serve Windows apps too -- by means of Citrix, or Microsoft Terminal Server, or VNC (Virtual Network Computing, http://www.uk.research.att.com/vnc/). But unlike X apps, Windows apps aren't built with the expectation that they'll be used this way.

• Mozilla/XUL. The newly-componentized Mozilla, coupled with XUL (XML User-interface Language), aims to be more than a browser. The goal is an application construction kit that enables development of new user interfaces tied to a range of back-end services and data sources. It's a great idea, but there aren't any compelling, proof-of-concept Mozilla/XUL apps yet. And as with DHTML, there's that nagging concern about cross-browser portability.

Rethinking client-side Java

It's been conventional wisdom, for a couple of years, that Java's best use is server-side. Java application servers are widely accepted as a mature, stable, scalable platform for the kinds of network services that can play to first-generation Web clients. But Java hasn't yet shown convincingly that it can deliver next-generation Web clients. Why not? Performance is one oft-cited problem; limitations of the security sandbox are another.

Still, the fact that client-side Java hasn't yet delivered the goods doesn't mean that it never will. I spoke recently with Bernie Thompson, president of VistaSource, a subsidiary of Applix. VistaSource is working to extend Applixware, the popular Linux office suite, into the ASP space. Bernie showed me an eye-opening demo, which you can see too at http://www.anywareoffice.com. Here's a picture of AnywareOffice in action:

Applixware with a remote Java face

In AnywareOffice the Applixware suite runs server-side, but displays in a lightweight, intelligent Java client.

In this scenario, you download just one small Java applet. It launches, displays, and controls Applixware apps -- the word-processor, the spreadsheet, the email program -- in a manner reminiscent of conventional remote-control solutions. But there's a twist. The protocol spoken between the client and the remote apps isn't about low-level mouse and keyboard events or bitmap and vector graphics operations. It's about application-level events like copying or graphing a range of spreadsheet cells.

What enables this scheme, Bernie says, is the aggressive work the Applixware developers had already done to cleave presentation from core function in their suite of Linux productivity apps. A new GTK interface was the first fruit of that effort, but AnywareOffice exploits the presentation/function split in a more radical and exciting way.

I'll admit that, so far, I don't find AnywareOffice to be a compelling alternative to locally-installed applications. But it does work, it's a fascinating proof-of-concept, and it's a really clever and pragmatic approach to client-side Java.

Component strategies

VistaSource apps are componentized in several ways. In addition to cleaving user interfaces from core engines, they carve up the engines themselves into scriptable components. Using a Visual Basic-like facility called SHELF, programmers can recombine the parts, create custom GUI interfaces, and integrate foreign apps and datasources.

I credit Microsoft with pioneering this approach to componentized and scriptable apps. The MS Office apps have for years defined "object models" that package their capabilities so that controlling scripts can reuse them. Integrators are constantly finding new ways to exploit this setup. Recently, in the programming newsgroup, Jonathan Brickman talked about how he's cobbled together a solution that connects IBM's PCOMM (Personal Communications, a host emulator) to MS Access.

Frankly, it's neat. It takes a bit of fiddling, but it's neat. Right now I've set up key-macros in IBM's PCOMM to run Perl (ActiveState Perl) scripts which then reach all the way into the class module of a Microsoft Access form to run public subs. Works deliciously, and amazingly fast.

Even niftier is that any app with OLE automation hooks can be scripted equally well in any language that's adapted to ActiveX scripting. There is essentially no difference between VBScript, JavaScript, PerlScript, or PythonScript when used at this level. All can make the same CreateObject call, and diddle the controlled app's object model in the same ways. It's not about the language, it's about the object model and what it can do.

Michel Pelletier chimed in with a perspective from the Zope community, where the recent announcement of Perl for Zope has created some controversy.

The language issue is minor. What matters is that you have a well-defined object model with clear interfaces. It wouldn't matter if the core of Zope were written in Python or FORTH if, from your perspective and the perspective of your language, the model and interfaces are well-defined.

Microsoft didn't have to make Perl and Python the effective equals of VBScript for the purpose of gluing components together. It could have tried to push VBScript as the preferred alternative. But to its credit the company has often understood that a components-and-glue architecture is what really matters, not what flavor of glue.

Whither Windows?

I'm filing this column before Microsoft's Forum 2000 event, so I don't yet know what the NGWS (Next Generation Windows Services) announcement will be. Neither does Dave Winer, but he's published what looks to me like a really good guess:

Imagine a word processor integrated into the Web browser (MSIE of course) and a toolbar that makes it easy to switch to your presentation program, spreadsheet, schedule, contact list, mail app, draw program, etc. All with a consistent user interface, and deep integration with Web services, that the client talks to through SOAP.

And while the code for these apps resides on your local hard disk, they are updated automatically, presumably with user confirmation. You pay Microsoft for this software, but it's a subscription fee, not a traditional software license. (Just like Frontier!)

Some of your stuff is publicly readable, some is not. All your information is stored on the server. So when you go on a trip, with a cellphone or a laptop, or are at a offsite, or a sales call, you can tap into the data, view it, edit it. It's like Yahoo with higher-level software running on the client.

It makes sense. The client software can use Web-friendly XML-over-HTTP protocols for remote storage (WebDAV) and remote service invocation (SOAP). And it can leverage the combined strength (and near-ubiquity) of both Windows and MSIE to create advanced user interfaces backed by open network services.

No matter how this plays out, I hope that strategies like the ones that Mozilla and VistaSource are pursuing will prove viable. It's not enough that network services are open, interoperable, and multiply implemented. Clients must be too. That's clearer than ever now that the likes of Napster and Gnutella are blurring the client/server distinction, and showing that the Internet is, most powerfully, a network of peers.

Late-breaking update

Well, I've read the Forum 2000 presentations, and watched the webcasts, and I think Dave got it just about right. On the client side, Microsoft's ambitious .NET platform (formerly NGWS) transforms the browser into an always-editable "universal canvas" on which heterogenous datatypes fluidly interact. One enabler here is universal representation of data in XML -- which, coincidentally, was the theme of my last two columns on MathML and SVG. Another key enabler is a software delivery mechanism that really works. The network computing initiative proceeded from the assumption that you can't push lots of software down to PCs, manage it sanely there, and effectively synchronize all the different devices people use. It's true that Windows has so far spectacularly failed this management challenge. Linux people are right to call attention to that fact, but wrong to indulge in an orgy of self-congratulation. Despite Eric Raymond's pessimistic predictions, Win2K did ship. And it breaks new ground with configuration technology (e.g., the system installer) that could challenge the central premise of network computing, and make .NET's client-side strategy feasible.

The Forum 2000 demos drive home a number of key points which I've been harping on for years, including:

• The read/write Web. So far, the Web's mainly about consuming, not producing, rich content. That's got to change, and .NET's always-editable canvas is exactly right.

• Metadata-enriched documents and messages. In the .NET demos, web pages and email messages that mention things like company or product names can recognize and "Smart Tag" these words, so that appropriate behavior (quote the company's stock price, order the product) attaches to them in all contexts.

• Automatic software componentization. On the first-generation Web, the same URLs that deliver interactive services to people can, with ingenious duct-taping, supply programmatic services to scripts. On the next-generation Web, there's much less need for duct-tape and ingenuity. Services don't emit HTML directly. They emit XML which can be rendered on a range of devices (PC, phone, tablet). And they also advertise their capabilities in the form of XML (SOAP) interfaces that other services can discover and use.

There are no new ideas here. Everyone wants to live in the world Microsoft is envisioning with .NET. What many of us don't want is for Windows to be the only viable client OS, and MSIE the only viable browser -- whether or not these products come from one Microsoft or two Microsofts. My hope, and my guess, is that diversity -- governed by standards -- will prevail. Linux, Java, and Mozilla: please make it so!

---

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads

This work is licensed under a Creative Commons License.