Jon Udell
The GUI revolution rewrote most of the rules for applications. But the File Open menu item in nearly all Windows and Macintosh software betrays one deeply rooted assumption that has yet to change. Programs still expect to create, write, and read ordinary disk files.
A programmer awakened from a 25-year coma would be overwhelmed by the snazzy APIs that control graphics, fonts, messaging, and other system services, but he or she would find the humble I/O functions used to store and retrieve documents quite familiar. Some of today's document managers can intercept File Open, but that's a stopgap. Robust, flexible control of shared documents won't really be possible until applications abandon direct file access in favor of
the sort of mediated access that OLE's structured storage and OpenDoc's Bento provide.
A compound document stored using either of these technologies is more like a mountable volume than a file. It has its own internal directories and files that supply persistent storage for the pieces of a document. OLE 2.0 objects use storages and streams; OpenDoc parts use storage units and values. Because each piece of content stores to its own ``directory'' or ``file,'' fast incremental saves can occur. There's no need to rewrite the entire ``volume,'' as current applications typically do.
Because the compound document is self-contained, OLE and OpenDoc can track links within compound documents. (Tracking them across documents, however, remains a thorny problem that can only really be addressed once these storage architectures migrate into the operating system and network substrate.) Transaction controls enable users to undo and redo changes. The first release of OpenDoc will also support multiple drafts of
a document, a feature that's still on the drawing board for OLE.
For vendors of document managers, the key point is that OLE and OpenDoc will spawn a new generation of applications that access compound documents only by way of high-level APIs. Because both storage systems are built to be replaceable, these APIs can in theory be redirected across networks to document servers. How might that work in practice? Microsoft OLE architect Tony Williams points out that in the near term, on Windows 3.x and Chicago, a document manager might embed content handled by OLE 2.0 applications in a shell that communicates with a server-based implementation of OLE structured storage.
That's better than hooking File Open, but it's still less than ideal because nothing prevents users from making an end run around the document manager and using applications in a stand-alone manner. Cairo will enable a more robust solution, says Williams, because document engines will be able to use its installable file-system mechani
sm to make server-based document storage available to clients in a way that's transparent to all applications.
Jon Udell is a BYTE senior technical editor at large. You can reach him on the Internet or BIX at
judell@bix.com
.
Distributed Document Management with OLE and OpenDoc
