Article View: comp.client-server
Article #96Re: My personal ideas on Client/Server
From: Lawrence D'Oliveiro, Waikato Uni...
Date: Thu, 08 Oct 1992 21:56
Date: Thu, 08 Oct 1992 21:56
41 lines
2998 bytes
2998 bytes
In article <1b0r3eINNne5@gap.caltech.edu>, toddpw@cco.caltech.edu (Todd P. Whitesel) writes: > ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > >>Apple's AppleEvent Object Model seems to me to be one step on this road, which > > Yes, but it's only a step. I would love to be wrong on this, but AppleEvents > seems to be more of a kludge based on the existing Event architecture that is > inherent in the Mac GUI. I have not been keeping current on this but as of last > summer I was not too impressed by AppleEvents. I hope it has improved since, or > that I did not get to see the whole story, because what I did see looked quite > lacking when compared to OLE. That's strange. I thought of OLE as being roughly equivalent to Publish/ Subscribe under Macintosh System 7, only without the network transparency. That is, it allows you to embed a data object in one document, that actually comes from another document (possibly another application). Any updates in the original document are automatically propagated to subscribers, and the subscriber can also invoke a "Go To Publisher" function (which relies heavily on the AppleEvent infrastructure in order to work), which automatically brings up the publisher document (perhaps launching the corresponding application if it isn't already running), and autoscrolls it to the portion that was published. AppleEvents do more than this. The Object Model, in particular, gives a way to reference objects like windows, documents and files, and parts thereof, eg "find all the bold text on pages 2 to 4 of document Fred and make it blue". 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. 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. Lawrence D'Oliveiro fone: +64-7-856-2889 Computer Services Dept fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00 Actually, of course, they were right within the circumstances of their study, but most of us can't afford such expensive circumstances. -- Bruce Tognazzini, "Tog on Interface"
Technical Details
Message-ID:
<1992Oct9.105603.11328@waikato.ac.nz>Path:
arc1-ca.pugleaf.net!sparky!uunet!gumby!wupost!waikato.ac.nz!ldoReferences:
<1992Oct8.013106.21116@ryn.mro4.dec.com> <1992Oct8.155058.11308@waikato.ac.nz> <1b0r3eINNne5@gap.caltech.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!gumby!wupost!waikato.ac.nz!ldo From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Newsgroups: comp.client-server Subject: Re: My personal ideas on Client/Server Message-ID: <1992Oct9.105603.11328@waikato.ac.nz> Date: 9 Oct 92 10:56:03 +1300 References: <1992Oct8.013106.21116@ryn.mro4.dec.com> <1992Oct8.155058.11308@waikato.ac.nz> <1b0r3eINNne5@gap.caltech.edu> Organization: University of Waikato, Hamilton, New Zealand Lines: 41