3 ms·

Taligent and OO frameworks in general had a massive impact of hype/unreality across the industry that spread to other other desktop or networked OO technologies

Taligent and OO frameworks in general had a massive impact of hype/unreality across the industry that spread to other other desktop or networked OO technologies, such as OpenDoc, CORBA, and WS-*. COM/DCOM/COM+ and OLE got caught in this and mostly succeeded in its niche but remained terrible complicated.

Shebanator 8y ago
It isn't fair to blame Taligent for that hype. Several of these systems existed before Pink/Taligent project was ever discussed publicly. Heck, we used to talk about how our stuff was better than COM and CORBA all the time. And OpenDoc was developed more or less simultaneously with Pink IIRC. But its been a long time and I never worked on OpenDoc so I might have the timing off a bit on this one.
atombender 8y ago
There was also IBM's SOM (System Object Model), used extensively in OS/2. SOM/DSOM was inspired by CORBA, just like COM. All of them uses an IDL and are based on querying for supported interfaces, which is a very powerful mechanism. They all died except COM, which remains the basis for most APIs that Microsoft release these days (even after a brief stumble with .NET where they, if I remember correctly, they tried to kill COM). It's a great technology, and it's a shame that Microsoft didn't open it up and turn it into a truly cross-platform technology. What didn't take over the world was this notion of object-oriented documents, which was what OpenDoc and Taligent were all about. This idea that content came with behaviour; you could embed an object from one app into another, e.g. a piece of an Excel table into a Word document, and the table would be live-updateable within Word, with all your interactions basically going between processes as COM calls, with the OO behaviour following the embedded content as it moved around, even when copy-pasted between documents. Very powerful, but super brittle. I used embedding a lot in the 1990s, trying to achieve what the PR told me should be feasible and easy, but it invariably ended with app crashes.
- p2t2p 8y ago
  They didn’t die. CFPlugin in Core Foundation that runs on every iPhone and Mac is an implementation of COM
  - atombender 8y ago
    "They all died except COM". And I would argue they CFPlugin is only really inspired by COM, it's not the real thing. It's just IUnknown and the same class layout: > The CFPlugIn model is compatible with the basics of Microsoft's COM architecture. What this means is that CFPlugIn Interfaces are laid out according to the COM guidelines and that all Interfaces must inherit from COM's IUnknown Interface. These are the only things that CFPlugIn shares with COM. Other COM concepts such as the IClassFactory Interface, aggregation, out-of-process servers, the Windows registry, etc... are not mapped. http://mirror.informatimago.com/next/developer.apple.com/documentation/ReleaseNotes/CoreFoundation/CFBundleAndCFPlugIn.html http://mirror.informatimago.com/next/developer.apple.com/doc...
- parasubvert 8y ago
  It turns out that hyperlinking / embedding shouldn’t involve you giving your memory address space to someone else - who knew :) And really, the web/REST wound up being the object oriented document framework we were all looking for. It was terribly inefficient at first (and is still) but was architecturally simpler. The main issue is no one thought it would be possible to replace Windows with a cross platform GUI, and no one thought hypertext/hypermedia - a mostly academic concept at the time beyond HyperCard - would be that GUI. https://www.slideshare.net/StuC/oopsla-2007-the-web-distributed-objects-realized?from_m_app=ios https://www.slideshare.net/StuC/oopsla-2007-the-web-distribu...
  - atombender 8y ago
    Right — as I remember, if you embedded an Excel object into Word, the Excel part was implemented in a DLL that loaded directly into the Word process space. This would have been so much more stable if it instead started a headless Excel server process. With DCOM, this kind of cross-process COM worked great, but that came much later. OLE 1.0 preceded COM by several years.

Shebanator 8y ago

It isn't fair to blame Taligent for that hype. Several of these systems existed before Pink/Taligent project was ever discussed publicly. Heck, we used to talk about how our stuff was better than COM and CORBA all the time. And OpenDoc was developed more or less simultaneously with Pink IIRC. But its been a long time and I never worked on OpenDoc so I might have the timing off a bit on this one.

atombender 8y ago

There was also IBM's SOM (System Object Model), used extensively in OS/2. SOM/DSOM was inspired by CORBA, just like COM. All of them uses an IDL and are based on querying for supported interfaces, which is a very powerful mechanism. They all died except COM, which remains the basis for most APIs that Microsoft release these days (even after a brief stumble with .NET where they, if I remember correctly, they tried to kill COM). It's a great technology, and it's a shame that Microsoft didn't open it up and turn it into a truly cross-platform technology. What didn't take over the world was this notion of object-oriented documents, which was what OpenDoc and Taligent were all about. This idea that content came with behaviour; you could embed an object from one app into another, e.g. a piece of an Excel table into a Word document, and the table would be live-updateable within Word, with all your interactions basically going between processes as COM calls, with the OO behaviour following the embedded content as it moved around, even when copy-pasted between documents. Very powerful, but super brittle. I used embedding a lot in the 1990s, trying to achieve what the PR told me should be feasible and easy, but it invariably ended with app crashes.

p2t2p 8y ago
They didn’t die. CFPlugin in Core Foundation that runs on every iPhone and Mac is an implementation of COM
- atombender 8y ago
  "They all died except COM". And I would argue they CFPlugin is only really inspired by COM, it's not the real thing. It's just IUnknown and the same class layout: > The CFPlugIn model is compatible with the basics of Microsoft's COM architecture. What this means is that CFPlugIn Interfaces are laid out according to the COM guidelines and that all Interfaces must inherit from COM's IUnknown Interface. These are the only things that CFPlugIn shares with COM. Other COM concepts such as the IClassFactory Interface, aggregation, out-of-process servers, the Windows registry, etc... are not mapped. http://mirror.informatimago.com/next/developer.apple.com/documentation/ReleaseNotes/CoreFoundation/CFBundleAndCFPlugIn.html http://mirror.informatimago.com/next/developer.apple.com/doc...
parasubvert 8y ago
It turns out that hyperlinking / embedding shouldn’t involve you giving your memory address space to someone else - who knew :) And really, the web/REST wound up being the object oriented document framework we were all looking for. It was terribly inefficient at first (and is still) but was architecturally simpler. The main issue is no one thought it would be possible to replace Windows with a cross platform GUI, and no one thought hypertext/hypermedia - a mostly academic concept at the time beyond HyperCard - would be that GUI. https://www.slideshare.net/StuC/oopsla-2007-the-web-distributed-objects-realized?from_m_app=ios https://www.slideshare.net/StuC/oopsla-2007-the-web-distribu...
- atombender 8y ago
  Right — as I remember, if you embedded an Excel object into Word, the Excel part was implemented in a DLL that loaded directly into the Word process space. This would have been so much more stable if it instead started a headless Excel server process. With DCOM, this kind of cross-process COM worked great, but that came much later. OLE 1.0 preceded COM by several years.