The only other way for it to work may be if each component had a viewer that was free, but this would be more complicated.

Something like OpenDoc could happen within the OpenOffice project. Does anyone know enough about ODF to know whether it would support this?

Also I have not heard any other explanation that holds water. Because it was picking up in terms of popularity and support in the time before it was pulled and I clearly remember quite some very surprised (and angry) reactions, so it was clearly not dormant.
That the project was canned because the consortium did not manage to resolve the technical problems around the file specifications, as a guy from upper management told me recently, I find somewhat hard to believe.

Anyway, with Cocoa underneath it should all be much easier to implement, and in principle by anyone as I seem to remember that the specification was open… :-)

OpenDoc was an interesting idea, but despite all the fervent evangelism I heard for it, I was never convinced that the design had a real solution for different users having many different components, written by different people, with a variety of version-skew problems. Sure, the user could choose between 10 different versions of “the graph component”, but how would that actually work in the real world? Consider a campus setting, with different people choosing different components, and inevitably running different versions of the components they did have in common, and yet having to share documents across all those computers. To me, OpenDoc seemed like it would be one huge nightmare. Yes, I heard all the propaganda about how great it would be, but the proponents never showed how version-skew problems would magically disappear with “components” compared to “applications”. And OpenDoc promised it would deliver lots and lots of components, so it needed to have a real solution to those version-skew issues.

It also seemed extremely obvious to me that one of the main attractions of OpenDoc (as far as the proponents were concerned) was that it would allow developers to break the stranglehold of Microsoft Office. That’s a great idea — assuming you can get Microsoft to buy into it. But why would Microsoft *ever* build an OpenDoc version of MS-Office? And if MS-Office was never going to use these OpenDoc components, and MS-Office already had a stranglehold on the “office app suite” market, then OpenDoc could never hope to break that stranglehold.

Also, as a programmer, it seemed to me that C++ was a really bad language to be designing something this flexible. C++ is a plausible choice if you’re trying to code for speed, but not if you’re trying to code for mix-and-match components across multiple versions and written by many different developers.

So it seemed to me that the ‘Services’ model of NextSTEP (and now MacOS 10) provided some of the nice “small component” flexibility that OpenDoc wanted to deliver, but did so in a much more manageable manner. Yes, it is much less ambitious, but that’s why it is easier to implement a reliable result.

David McCusker did not write the Bento spec. He certainly was the engineer working on it and he was developing an urgently needed successor to Bento that came too late to make a difference. I believe the Bento spec was written by Jed Harris, but I’m not completely certain.

In the ten years since the end of the project, I’ve been aware of two “reinventions” of OpenDoc, independently, as far as I’m aware. One of these was at Adobe. Both concerned complex documents with component-like objects that operated on some content within the document. Neither came to anything. Maybe someday.

I saw OpenDoc a bit differently.

(1) It never worked very well

(2) Writing simple components wasn’t too bad, but writing a component that could embed other components was next to impossible.

(3) ODF came too late in the game and, while in some ways was needed, also made “parts” too big and slow to work on then current machines.

(4) Debugging was a nightmare. SOM was a nightmare.

Some pieces of OpenDoc were well thought out, but others were never thought out at all. Apple used to tell everyone how you could have a ’spell checker’ part, for example, even though there was no way to do a functional (non-visual) part.

The sad thing is that OpenDoc would be almost trivial in Cocoa and Mac OS X what with bundles for document files (simple i/o instead of Bento), introspective GUI elements, standard encoding and decoding of objects, background threads, and Quartz for graphics.

2 Gigs of memory and 2GHz machines wouldn’t have hurt either.

CyberDog was great, but I was never sure if OpenDoc really helped it at all.