This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Pluggable Components
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
Responding to James A. Robertson's assertion that buying and putting together components - at the user level - never works...
First, there is a whole industry of Photoshop plugins and other plugins for various host applications (video editing). If you don't work in those fields, you don't hear about them, but these kinds of components are a successful business for many companies.
Also, there was a brief time (some of like a Camelot) where Apple's OpenDoc seemed to be on the road to success, in spite of being written in C++ (which means that any component crashing would crash your whole host application.) Most of OpenDoc activity was on MacOS, though IBM built an implemention on OS/2 and someone (Apple?) built an implementation on Windows. While the WikiPedia says that the timing wasn't right (the rise of Java), I'd say that Apple's faltering finances at the time actually doomed it.
The most successful use of OpenDoc was CyberDog which had components to handle each of the internet protocols (http, ftp, mail, etc.) and mime types (html, images, etc.). There were at least two commercial word processors that were OpenDoc hosts, and we were eagerly awaiting ClarisWorks (now AppleWorks) reimplemented as OpenDoc components and host application (it was was demoed but never shipped). Web-sites (and maybe even OpenDoc components themselves tied to websites) to help you find and buy OpenDoc components were springing up. There were some companies offering free readers components and non-free editor components so you could distribute documents authored by commercial components and have people be able to read them. The true strength of OpenDoc over JavaBeans was that the "Bento" file format allowed creating a single document from multiple OpenDoc components.
When Apple had financial difficulties and accepted a large sum of money ("investment") from Microsoft, Microsoft required them to kill off OpenDoc because it competed with OLE/Com/ActiveX and kill off CyberDog because it competed with Internet Explorer. [This same agreement allowed Microsoft to retroactively license patents from Apple that it was violating.] Once OpenDoc was killed off, Microsoft's "ActiveX on MacOS" effort evaporated, leaving third-party "ActiveX on Mac" developers high and dry.
I regarded OpenDoc as overly complex, but it was technically workable. Java Beans were too simplistic - they couldn't be used without having a programmer put them together, and didn't have a document format like Bento. OpenDoc was actually easy for a user to use, but hard for a developer. If not for Apple's finances, and Microsoft's monopolistic threats, I think it would have succeeded. I think it would have been more easily successful if OpenDoc had been implemented on a robust OS (like MacOS X), maybe with each component running in a separate process space (so that one component crashing would not crash your entire app), and if the saved data included a rendering (an image/text format like PDF, so you didn't have to distribute "reader" OpenDoc components with your document), or if the OpenDoc components could have been embedded in your document (like fonts can be embedded in a PDF).
A re-implementation of OpenDoc (and the Bento file-format) using Cocoa/Objective-C would be very powerful (and easier for programmers) because it would be able to avoid a lot of C++ rigidity and overhead. Implementing in a almost crash-proof language like Smalltalk or Python would also be a win. If the actual components ran in separate address spaces, using some "distributed object" protocol, then it wouldn't matter what language your wrote the component in.
Previous Topic
