🚀 go-pugleaf

ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:

>That's strange. I thought of OLE as being roughly equivalent to Publish/
>Subscribe under Macintosh System 7, only without the network transparency.

This is probably true of OLE 1.0. I am no expert on OLE but 2.0 was supposed
to have network transparency and a considerably more powerful object model.

>This allows applications to call on the services of other applications, eg a
>word processing program doesn't need to provide drawing tools to manipulate
>graphics, it can make use of the services of an existing drawing program.

OLE does this also. The stuff I worked on was definitely for OLE 2.0, and it
was intended to be a toolkit in a DLL that would help third-parties retool
their apps for OLE 2.0 compatibility.

>AppleEvents aren't a scripting language per se, but they do provide the
>basis on which you can build a scripting system to coordinate tasks involving
>a whole bunch of applications working in concert.

OLE 2.0 is a more fundamental protocol that defines common app operations and
allows apps to speak to each other with a more powerful language that includes
both direct, pre-defined standard messages and more macro-like scripting. The
key difference is that with AppleEvents you _have_ to build the system -- and
Microsoft has implemented OLE on top of AppleEvents -- but with OLE you have a
lot of things built in. It seems to me to have a much broader scope than
AppleEvents.

It's been a year, so I'm pushing my recollection of OLE somewhat. I'll leave it
to somebody else who knows more to expound on the details. The only stuff I
know more about is basic architecture of the communications path between OLE
compliant apps, and what the common messages would be like. This has all been
handed out to developers so I _think_ it's safe for me to talk about it...

Todd Whitesel
toddpw @ cco.caltech.edu