Suppose we did outfit GroupCal with meeting and task objects. Since these things are more objectlike than relational, XML might be a good way to represent them. An XML-capable object database could serve up this data; XSL presentation services could render it in a browser; DHTML scripting could support interactive viewing and editing.
This is all very exciting but slightly ahead of the curve in terms of the installed base. Netscape is playing a catch-up game with XML; browser support for XSL is still experimental; the Microsoft and Netscape DHTML technologies are quite different. For the time being, web applications that manage complex data objects within a calendar framework rely on server-side production of HTML. This approach is time-honored (as Internet time goes, that is) but still really useful.
As we saw with the Microsoft Index Server (Chapter 8), one way to work with a software component that exports a web API is to treat it as a black box accessible only through that API. Anything that a user can do by way of a browser, a web-client script can do by manipulating URLs. This duality, inherent in all web software, can often enable startlingly simple solutions to seemingly hard problems.
When I first deployed GroupCal, a colleague asked if he could import data from his personal information manager (PIM) into GroupCal. My first response was: no way! But on reflection I saw that this was actually an ...