OpenDoc vs. OLE

When elephants fight, only the ants get hurt

By Jeff Alger, Consulting Methodologist

A monolith of American industry threatens to unilaterally impose a standard by virtue of its sheer size and dominance of the market. Quickly a consortium develops to counter the move; a rival standard is proposed, the hype wars begin. The lumbering giant points to the fait accompli: its technology is already in use throughout the world and will soon be a standard part of its operating systems on millions of machines. The upstarts point to technical advantages of their proposal and darkly hint at the threat to democracy and family values that will loom if the industry titan is allowed to further consolidate its grip. The press eats it up, sensing a David vs. Goliath story in the making. The battleground: component object-oriented software. The industry titan: Microsoft. The upstart consortium: Apple and IBM? Wait a minute. Am I the only one that sees something weird about this alignment? Age-old IBM a frightened upstart? Entrepreneurial Microsoft the lumbering giant? What’s going on here?

Unless you’ve been hiding underground the past few months - not a bad idea, actually - you’ve been ducking blows in the OLE (“Object Linking and Embedding”) vs. OpenDoc slugfest. Both address roughly the same issues: how to combine object-oriented software components into heterogenous documents, how to exchange data between programs, how to store and retrieve objects, how to distribute them across a network, how to allow objects to interoperate across programming languages and machines. Given these stakes, the battle may well be what both sides are claiming: the key to computing in the second half of the 90’s. But sorting out which is better and for what purposes is like trying to get directions to the nearest town from two people who are rolling on the ground trading rabbit punches. Let’s step back to a safe distance and take a dispassionate look at what’s really going on.

Of Objects and Markets

The basic technology at issue can be divided into basic four tiers of standards.

1. A standard for the binary representation of objects.

2. A standard mechanism for storing and retrieving documents containing arbitrary collections of objects.

3. A standard for how to allow users to combine arbitrary user-visible objects in their documents.

4. A standard mechanism for distributing and sharing objects between applications and over a network of dissimilar machines.

The first issue has to do with how objects are stored in memory. Microsoft’s standard is known as the Common Object Model (COM). The standard adopted for OpenDoc is IBM’s System Object Model (SOM). There is more than simple storage at issue. How do we allow different programming languages to create and access common objects? For that matter, just what is an object, anyway, and where should the line be drawn between an object at run time and the program source code used to create it? These are fundamental issues and the winner, if there is a single winner, of the current object wars will have a huge influence on object-oriented language designers for many years to come.

Older concepts of file systems and databases just can’t cope with the storage problems we face today. Both OLE and OpenDoc contain new standards, along with libraries that implement them, for storing and retrieving what are known as “compound documents,” files that contain nested collections of diverse sorts of objects. This, too, is likely to give the winner - if there is a single winner - a lot of throw weight in battles over other issues in the next generation of object systems.

Ah, yes, let’s not forget the users. They don’t directly see binary objects or compound document files or programming languages. To them an object is something they can point to on the screen or on hard copy and give a name. They rightly expect objects to be consistent and well-behaved no matter where they appear. They get frustrated at the arbitrary distinctions we’ve traditionally drawn between data that belongs in one sort of application and data that belongs somewhere else. “Wouldn’t it be nice,” Joe User might well say, “if I could simply copy or drag anything I can select into any other document in any other program and have it still work?” Indeed. That is the stuff of the user interface and portions of OLE and OpenDoc.

Finally, the arcane world of distributed objects. Neither side really has them yet, but in the struggle for control of tomorrow’s operating systems this is shaping up as potentially the most important part of the war. In a world of multiple machines and multiple virtual memory spaces, how do we tell one object from another? How are they created and destroyed? Do we store objects in their own little mini programs with separate address spaces, or combine them into a single memory pool? Can an object be shared between multiple documents or simply copied? Can one document contain objects that live on multiple machines? How do you handle failures, of networks, machines and users? Must a programmer write code having already decided which objects are to be distributed, or can those decisions be deferred?

With stakes like these, little wonder that the opposing sides are weighing in so heavily and so early. This is at once the next generations of object-oriented software technology, graphical user interfaces, and network operating systems. Waiting on the sidelines are the anxious software developers whose products must interoperate using one standard or the other; corporate developers hungry to lower their costs; retailers wondering what this means to the ways we package, price and distribute software; and programmers everywhere trembling at the thought that everything they once knew about writing applications might have to be relearned and knowing that they’d better pick the right horse or be left behind.

This issue contains more detailed descriptions of OpenDoc and OLE elsewhere, so I won’t go into a great deal of technical detail here. Instead, I’ll focus on comparing and evaluating the two products.

Back To School

Of all that has been said and written about OLE and OpenDoc, the only uncontestable claim is that both are complicated pieces of technology.

The OLE documentation numbers in the hundreds of pages, but if you really want to know what’s going on you have to read Kraig Brockschmidt’s 900+ page book Inside OLE 2.0, along with numerous more recent papers from Microsoft. Come to think of it, Brockschmidt’s book doesn’t even begin to talk about OLE Automation, the substrate upon which scripting is built in OLE. It wouldn’t hurt to attend a few conferences to get a sneak preview of the upcoming Chicago and Cairo operating systems. Since OLE is best used from within the Microsoft Foundation Classes (MFC) class library, allocate a few mental cycles to become familiar with that set of documents as well.

As to OpenDoc, I haven’t even been able to estimate the page count of the documentation yet. You can get a quick tour by pouring through a couple hundred pages of OpenDoc preliminary - very preliminary - documentation, then wade into the 500+ page System Object Model (SOM) documentation from IBM. Oh, and if you haven’t yet had the pleasure, take the opportunity to read up on the Drag and Drop Manager and the Code Fragment Manager (CFM), because they, too, are connected.

If you are trying to compare the two, be prepared to be inundated with all manner of position papers from both sides. The level of sniping in these “black papers” is exceeded only by the casual attention to the real facts.

Egad! Don’t these people know that we all have jobs and families? Learning either of these technologies well enough to write a simple component takes a few days. Learning enough to design a major project looks to me more like weeks of reading and training backed by a at least a few months of hacking. Learning enough to intelligently make a long-term strategic choice is nearly impossible, especially since one of them doesn’t even exist yet.

Ghosts Of Objects Past, Present and Future

One of the surreal aspects of the debate is that it isn’t always clear what’s been there for a long time, what’s new and what is still vaporware. The OpenDoc consortium has done a brilliant job of positioning OpenDoc,tomorrow’s concept, against OLE 2.0, today’s product. Microsoft plays into their hands by claiming OLE is better because it’s already shipping, then in the same breath turning around and claiming that their vaporware will be better than OpenDoc’s vaporware. This stuff gives me a headache. Let’s start the comparison by defining our terms. The following is the situation as of this writing in mid-June.

The Past

On the Microsoft side, OLE 1.0 shipped in 1990 and OLE 2.0, a major enhancement, shipped early last year. It is available today in final form on all Windows and Windows NT platforms and on the Macintosh. Microsoft, lover of big numbers, claims there are about 1.5 million customers using OLE-aware applications and that most of the major software vendors are already committed to supporting OLE, most of them already pretty far down along the learning curve.

On the OpenDoc side, there are a couple of precursor technologies such as the Drag and Drop Manager but that’s about it. In short, Microsoft is right, as of today OLE is shipping and OpenDoc isn’t.

The Present

As you read this, there are various alpha and beta versions zooming around both worlds, making it horribly confusing to keep score. OpenDoc is in release A6 on the Macintosh as of the Apple World Wide Developers Conference in May. This includes a very early release of the IBM System Object Model implementation for the Macintosh. OpenDoc has not made its way to any other platforms as of this writing, although one piece of the underlying technology, SOM, is supported by IBM on AIX and OS/2.

Meanwhile, Microsoft has seeded a “select” group of 5000 developers with a prerelease version of the distributed version of OLE. They have also begun beta testing of OLE Controls, a small-component extension to OLE that is both a close analogy to OpenDoc parts and to Windows VBX controls.

The Future

Microsoft is busy implementing their “Windows API Everywhere” strategy. They have licensed the source code to the Windows operating system to at least two other vendors who have demonstrated partial ports to Unix. They have committed to licensing the Windows and OLE source more broadly, although the terms have not been made public. Where Windows goes, so goes OLE. In addition, Microsoft is working with DEC to refine COM somewhat to go from the “Component Object Model” to the “Common Object Model.” In addition to driving everyone nuts keeping the two identical acronyms straight, this will enable DEC to port OLE to other operating systems including OSF/1. Microsoft claims that a port to MVS on IBM mainframes is also under way. It should be made clear what this means: The OLE standard, including the objects themselves, will interoperate across both Windows and non-Windows operating systems.

One of the worst-kept secrets in the computing world is the work Microsoft is doing on their next generations of the Windows and Windows NT operating systems. Daytona, the successor to Windows NT and already in beta testing, will include native support for OLE 2.0 built into the operating system. Chicago, the successor to the Windows operating system and a major enhancement of the user interface, blurs whatever line is left between where the operating system ends and OLE begins. Cairo is an object-oriented operating system built on OLE from the ground up. Another technology Microsoft already has well into the pipeline is an integration of OLE with ODBC database support. All, with the possible exception of Cairo, are scheduled for release within roughly the same time frame as a final release of OpenDoc, so it is fair game to project them into the equation. (I consider anything within six months to be “roughly the same time frame.”)

The OpenDoc consortium has committed publicly to making the source code to OpenDoc available and to port it to a variety of platforms. They point to “support” from systems software vendors Apple, IBM, SunSoft, Taligent, Novell, and Xerox “with many, many others expected to follow” according to one white paper. (italics added) It is unclear from their white papers and documentation exactly what is being supported by all these vendors, OpenDoc or only pieces such as SOM. The phraseology cryptically lapses into support for “CILabs technologies,” CILabs being Component Integration Laboratories, the formal entity behind OpenDoc.

Recently the OpenDoc crowd has announced that OpenDoc will be written in such a way that it can interoperate with OLE. Details to follow.

Binary Object Models

Both products allow you to create objects in such a way that they can be accessed from programs written in other languages. This is the stuff of so-called “binary standards” for objects, a subject that has kept lots of folks busy over at the Object Management Group for quite a while. The two approaches are Microsoft’s COM and IBM’s SOM and they couldn’t be more different.

The Component Object Model

COM embodies a sharp separation between binary objects and the object-oriented programming languages used to create them. The COM model is based on delegation, not inheritance. Rather than have one class derive from another, in COM you would likely form what is known as an aggregate of two objects. The container object would delegate to the component object in much the same way that a derived class would pass along messages to its base class. Aggregation can also be used to implement the equivalent of complex data members.

COM represents a C++ way of thinking of objects at run time. Methods are dispatched using something that you would swear was a vtable if you didn’t know better. In fact, you can use C++ derivation to create your aggregates, as long as you add the interfaces to direct a client to the right base class or data member. Yet, the model is not exactly C++. While servers may be written in terms of derivation, clients see a flat object space. There is more mathematical consistency than in straight C++; if you do the equivalent of typecast from derived to base, you are guaranteed to be able to typecast back to the derived class in a typesafe way. This reflexivity is one of several rules of consistency imposed by COM to maintain type safety.

Speaking of type safety, COM is safe very. The way you access an object is through an interface. Each interface is uniquely identified by an interface ID (IID). The way you obtain an interface from an object is, you ask it. The specific way one would typecast from “derived” to “base,” for example, would be something like this:

Derived* d = (Derived*)object->QueryInterface(kDerivedID);

This returns either a valid pointer or NULL to signify that the object doesn’t support that interface. That is, in order to typecast any object you have to go through the object, which can verify that the interface is valid for that object. This is all done in either C or C++. It is easy to wrap existing classes with COM-style interface wrappers.

Normally, you will use interfaces that represent standard C++ class interfaces. COM also provides a special interface called IDispatch that essentially allows you to query an object about its capabilities at run time and dynamically dispatch to it using symbols, not precompiled function calls. This provide low-level support for scripting and high-level development tools that need a dynamic environment. Because of the delegation model, an object can change its interface and implementation at run time, within certain limitations to insure consistency.

What is involved in using COM? Basically, you just write the interfaces and the code. If you are using C++, it’s no more complicated than writing any other C++ program, but with a couple of extra member functions to write such as QueryInterface and perhaps support for OLE Automation. If you are a C programmer, there are some nifty macros that reduce the problem to about the same level of complexity as using C++, although I have a hard time understanding why anyone would want to use C rather than C++ for this particular purpose. If you are using other languages, you have to check with the language vendor. Many are being adapted to work with COM but it’s not a universal standard yet. As they are adapted, however, the objects you create using, say, C++ code will be accessible and manipulable from, say, Smalltalk and vice versa. Learning to use COM involves perhaps a few dozen pages of manuals and less than a day of effort.

The System Object Model

SOM frightens me. It really does. It’s as if a bunch of people with the software equivalent of bazookas sat around one day and said, “Hey, let’s see if we can solve a problem nobody cares about by taking all the major object-oriented languages and blasting them into smithereens.” Brrrr. What’s even more frightening is that no one seems to be taking IBM to task for this unbelievable act of engineering hubris - except Microsoft, and that is written off as competitive snarling. The rest of OpenDoc is a reasonably good piece of engineering, but if SOM comes within a hundred yards, duck.

The stated objective behind SOM is to provide “language-neutral” access to objects. It is based for the most part on the Object Management Group’s (OMG) efforts to standardize the binary representation of objects. The run-time model is dynamic, supporting run-time inheritance and polymorphism. Thus, you could use all the features of a Smalltalk or Common Lisp Object System (CLOS), such as creating classes or changing their derivation on the fly.

However laudable these aims, the result is an over-engineered mess. To use it, you have to first describe your objects using yet another language, the SOM Interface Description Language (IDL). This isn’t just a minor detail, but another programming language to master. The syntax is sort-of-Smalltalk, sort-of-C, sort-of-C++ but in the end it is IDL. It is chock full of macros, modifiers, conventions, and isms.

SOM isn’t language-neutral; I would call it C++ -hostile and sort of Smalltalk-friendly. The role of C++ is reduced to implementing and calling specific member functions. The C++ notions of class, derivation, constructors, destructors, operators, overloading, etc., are all subsumed by the IDL model. SOM does not support private, protected and public member specifications, unless you consider surrounding a member function with “#ifdef __PRIVATE__/#endif” to be “support.” In fact, it is hardly worth bothering to use C++ with SOM, since C does just about as well with what’s left. SOM is a slap in the face of the C++ community.

OK, so you don’t like C++. If what you really want is dynamic binding and such, Smalltalk or CLOS will do better than IDL at those tasks. Garbage collection is based primarily on reference counting. While this is also true of COM, COM doesn’t pretend to provide language neutrality. It is difficult to envision true Smalltalk- or CLOS-style programming using a reference-counted garbage collection scheme. SOM doesn’t have anything resembling code blocks from Smalltalk and Objective-C or macros from CLOS. There obviously aren’t anywhere near the diversity of libraries for SOM that there are for Smalltalk, Object-C or CLOS. It isn’t worth going further, because I wouldn’t stop for several days. To paraphrase the former candidate for Vice President and current Treasury Secretary, “I worked with Smalltalk. Smalltalk was my friend. Sir, you are no Smalltalk.”

Interoperability? COM is living proof that you can provide an equivalent level of language interoperability without first tossing conventional languages into a Cuisinart. Whether you like COM or not is not the issue; the issue is that SOM is to interoperating what a flamethrower is to mowing the lawn. Yes, the lawn won’t grow back for a while, but haven’t we forgotten something important about lawns?

The development lifecycle is bizarre. First, decide which objects should be treated as SOM objects and which as normal, local objects. If you later change your mind, it’s bad news unless you’re paid by the hour because you’ll have to pretty much start over. Next, write a description of your objects in IDL, then compile them using an IDL compiler. This funnels your description through an “emitter” which spits out template C or C++ or Smalltalk or whatever code. Fill in the blanks. Compile again, this time using your language compiler. On the client side, emit stuff to include with your program. Write your program. Compile. In short, take all your worst nightmares about software management and play them at fast forward with the color knob twisted all the way to green.

The funny thing is, there isn’t even a significant problem solved by SOM. Other than the vendors who forked over big bucks to participate in the Object Management Group, I haven’t noticed a particular groundswell of opinion that language interoperability is a big issue. Language vendors have managed to do a creditable job at that without having to toss everyone’s salad. A binary standard for how C++ objects are represented in memory would achieve 90% of what SOM does with about 5% of the hassle, because then C++ itself could also serve as the object interface description language. Extensions to C++ to handle intermixed dynamic and static binding of methods - permitted by the language spec, by the way, which does not require the use of vtables - would solve the rest. Even without that, as COM demonstrates, idioms for using C++ more intelligently can solve just about any problem a developer will encounter in real life. That’s what James Coplien’s book Advanced C++ Programming Styles and Idioms is all about.

It is telling that in OpenDoc one is only expected to use SOM for a small subset of objects that have to be accessed externally. The rest is conventional C++, including almost all of the OpenDoc Parts Framework class library.

Documents and Storage

Both products allow you to store arbitrary, nested, versioned objects in compound document files. Both use streaming as the primary means of turning an object into bits and back. Both provide a way to browse through a compound document file and extract only those pieces you care about. Both provide a way to maintain multiple versions of a document or specific objects within it. There are differences in the area of document storage, but not compelling ones in either direction.

The one major difference coming up is that the Structured Storage model of OLE is being built into the file system of upcoming Microsoft file systems. This will provide a higher level of protection and performance than one can expect from Bento, the underlying storage technology of OpenDoc. This will also fix a nagging problem with the current version, which uses file path names to locate things. If the user moves the file, OLE might not be able to find it when needed. SOM also uses path names, but OpenDoc apparently will stick to the Macintosh model of file references, which stay the same as a file is moved around.

Structured Storage has slightly better features for recovering from a crash, including a very good feature called “Transacted” mode, in which all changes are considered temporary until all are committed together. Under OpenDoc, changes are written incrementally, possibly leaving a file in an inconsistent state following a crash, at least as far as the user might be concerned. Structured Storage also makes it a little easier to implement a “Revert” command without having to duplicate the entire file, only the parts that change; OLE keeps track of which is which.

The User’s Perspective

OpenDoc looks very good at the user level compared to OLE. Apple has done a very good job of thinking through how a user will interact with parts that have different commands and different user interfaces for those commands; i.e., menus. In OpenDoc, the integration of the parts into a single user-visible document is pretty close to seamless. Click on an object and the user interface changes state as appropriate to that object. New menus show up, old ones go away, windoids come and go as they should. The standards for borders and other user feedback seem thoughtfully designed.

Comparing OpenDoc’s user interface directly to OLE’s is difficult because there are several levels of OLE support possible. Where OpenDoc has essentially one interface and architecture, OLE can potentially support several. This is not so much because the user will appreciate this as that OLE presents a graduated scale of options to the developer, depending on the degree of integration you want or how OLE-capable you are.

A minimal treatment is to turn a normal Windows application into an OLE-aware application, capable of being an OLE “server.” That is, the application’s document becomes a component in some other application’s - a container’s - document. When the user “activates” the embedded object, the originating application is fired up and the actual editing takes place in a separate, temporary window. This is a slight extension to the user’s concept of using two separate applications: There are still two apps, but now the data is combined. It is not necessary to have the original app around if all you want to do is draw and print, since the PICT or metafile needed to do those is er, embedded into each OLE server object. (By the way, OLE automatically turns PICTs into Windows metafiles and back when objects migrate between Macs and Windows machines.) Only if the user needs to edit or you want to do something fancy like animation or sound do you need the original application installed. Most of the work involved in becoming an OLE server is in supporting a stream interface for the clipboard and drag and drop to use in moving the data around.

On the receiving end is the OLE container, an application whose documents can contain OLE components. Like becoming a server, turning an arbitrary application into an OLE container is relatively easy although more involved than writing servers. A container-server is simply a combination of the two techniques. At this level one gets the use of drag and drop and OLE-style clipboard use.

It is also possible to create OLE servers that edit in place, rather than opening a separate window. These modify the user interface environment around them in much the same way that OpenDoc parts do: menus and toolbars swap to reflect the currently active server. This is known as in-place activation.

The next and most common treatment is an in-process server. This is a dynamic linked library (DLL) that runs as part of the client application, though it is loaded at run time. This allows lightweight display or editing code to go with the object without having to bring along the entire originating application.

Finally, there is the future: OLE Controls. These are direct analogies to OpenDoc parts. They are scriptable, they activate with single clicks, not double, even on deeply nested objects, and they run as part of the client process. In the long run they look a good bet to replace VBX controls in the Windows world.

So, which user interface is better? Unfortunately, the comparisons by the combatants aren’t always fair or accurate. More than in any other arena, one has to ask, “What version are you comparing to, today’s or tomorrow’s?” If you compare the user experience with OpenDoc parts to OLE 2.0’s out-of-place servers in OLE, OpenDoc wins, hands down, from the user experience. Users will appreciate not having to remember when to use a single click and when to use a double click to get the job done and not having to understand much about the underlying nested structure of their objects.

If you compare OpenDoc parts to OLE Controls, the differences become pretty minor both ways. Both activate in exactly the same way, with a single click, even on nested components. Both activate in-place. Both run in the same task space as the client application, although an OLEcontrol can run in its own space if written that way. OpenDoc still maintains a small edge because of its support for arbitrarily shaped borders around objects; as of today, OLE is limited to rectangular borders. However, Microsoft has stated publicly that they, too, are considering supporting funny-shaped embedded objects, so that distinction may not last for long.

So which user interface is better? Today, OLE 2.0 because OpenDoc isn’t here yet; this is one of those issues that has gotten clouded by comparing OLE today to OpenDoc tomorrow. Tomorrow, when OLE Controls and Cairo have come along, I suspect OpenDoc will still have the edge, though both will be excellent treatments.

Distributing the Objects

Finally, let’s talk about what happens when we stop looking at individual applications and start looking at entire networks. COM becomes a network-wide distributed object system by simply installing the Networked OLE DLL in place of the OLE 2.0 DLL. That’s it. No recompilation, no changes to source. OpenDoc requires the use of the Distributed System Object Model, or DSOM, the distributed extensions to SOM. DSOM is certainly a creditable implementation of distributed objects and the techniques used are very well-established. However, under straight DSOM, you have to decide up front what you want to distribute and what you don’t. The interfaces for creating, destroying and in some cases using objects under DSOM are quite different from those under straight SOM. The programming needed to implement DSOM servers adds even more complexity. This is not a trivial retrofit to existing code. Plus, it’s SOM++ and all that it implies.

Apple states that OPF will hide the differences between SOMand DSOM, and between local and remote objects. The A6 release code and documentation do not indicate how that will be done. [By the time you see this, Apple may have made this clear through a subsequent release - Ed stb]

As Microsoft is apt to point out, this relative simplicity of COM does not mean that the COM implementation is less robust; the opposite seems to be the case. For example, DSOM does not have any built-in capability to detect and resolve deadlocks while COM handles them properly. Programmers must manually design for support of multithreaded object servers under DSOM; not so under COM because of the operating system-level infrastructure underneath.

White Noise

There is a recurring problem with comparisons of the two technologies emanating from both camps. Both approaches are fundamentally sound and many of the “problems” can be fixed with little or no effort. For example, one of the most vocal criticisms of OpenDoc from Microsoft is that OpenDoc parts must be accompanied by the corresponding part handler code or they can’t be displayed or printed. In other words, if you don’t have the right part handlers installed on the user’s machine, she will just see big gray boxes where her objects should be. However, the OpenDoc folks could solve that at a stroke by requiring that all OpenDoc parts store a PICT image as a property, thereby allowing displaying and printing with or without the right part handler code.

There are outright distortions that show just how sloppy the discussion has become. For example, one supposed knock against OLE is that to activate a nested object one has to double click on the outermost object, then keep activating inward one object at a time. There are two problems with this: It is within the OLE spec to implement activation outside-in or inside-out a la OpenDoc and it is also within the OLE spec to use a single click rather than a double click to activate an object. OLE Controls illustrate these two facts by implementing an OpenDoc-style activation model - inside-out, single-click - while staying within the OLE specification. Apple also claims that the way that OLE finds server code, using file pathnames that a user can easily screw up, is a serious flaw in OLE. What Apple doesn’t point out is that Cairo, which is supposed to ship not too far from OpenDoc final, fixes all that. Granting equal time, Microsoft has decried OpenDoc’s requirement for part viewers on all the machines in a network that might need to access parts. This, it is claimed, requires engineering the software separately for each platform, neglecting to mention that the OpenDoc Parts Framework (OPF) class library is designed to provide source code compatibility across platforms and that only on machines supporting the Windows API is similar source compatibility assured for OLE. Both sides cite the supposedly extraordinary difficulty in using the other guy’s product, forgetting to mention that each has class libraries, OPF on the one hand and the Microsoft Foundation Classes on the other, that dramatically simplify things. Excuse me, my headache is back.

To Market, To Market, Lickety Split

Both OpenDoc and OLE present acceptable user interfaces. There are differences, and as of today’s specifications OpenDoc gets the nod. How much of a nod depends on your particular priorities, for while OpenDoc does, in fact, do a better job of improving the user experience, OLE is likely to get you into the component software market faster and is certainly not a bad user interface even today. In the time since Apple first started working on Taligent and later OpenDoc, Microsoft has released a steady stream of new, incrementally improving technologies, bringing the market and the industry along with them slowly but very surely. There are now hundreds of vendors of everything from DLLs to VBX controls to OLE objects that have experience in the marketplace for component software. It will take years for the Apple world to gain that level of experience with how to develop, package, price and support the sort of components needed to make OpenDoc a success.

Microsoft provides as seamless a growth path into OLE as OpenDoc presents a seamless user interface across parts. Companies that already know how to write Windows applications can start shipping OLE-aware applications with an absolute minimum of effort and with little or no rewriting or redesign of existing code. The ramp from there is gently sloped until one is shipping OLE Controls, the full-fledged equivalent of OpenDoc parts. Going from single-process COM to fully distributed objects involves no more than installing a new DLL. There are no new programming languages to learn, as there are with SOM. It is foolish to claim that all of these dollars and cents issues should be swallowed up by a single-minded quest for better user interfaces.

There are two different business models at work, Apple’s quantum leap approach to software and Microsoft’s continuous incremental refinement. I suspect there is room in the market for both, as long as the technological differences are narrow enough. Eventually, I expect this intense competition will reveal a case study in the way market economies are supposed to work: Both the OpenDoc consortium and Microsoft are being pushed to adopt the best features of each and this is improving the lot of consumers on both sides of the aisle.

The Mid-Term Report Card

OK, let’s cut through all this and reduce it to letter grades. To do this, I’m going to use a reasonable extrapolation of what will be available within twelve months; anything else gets too messy to do a direct comparison.

Subject OLE OpenDoc

Binary object standard B F

Compound document storage B B-

User interface A(1) A+

Distributed object support A+ B(2)

Ease of learning B C

Ease of adoption (3) A C

Overall grade A- B-

(1)Assumes OLE Controls and Cairo. Without these the grade would be C+ (no pun intended).

(2)This is purely for the DSOM extensions, since SOM itself is graded separately.

(3)Principally the smoothness of the growth path from existing development practices.

Overall grades are weighted evenly across all subjects. I won’t quibble with anyone that wanted to assign the user interface more weight, which would improve OpenDoc’s grade but not lower OLE’s. Were OpenDoc to use COM rather than SOM, the overall OpenDoc score would climb dramatically. Well, I can dream, can’t I?