Re: Nice Automator article on O'Reilly
Re: Nice Automator article on O'Reilly
- Subject: Re: Nice Automator article on O'Reilly
- From: has <email@hidden>
- Date: Fri, 6 May 2005 16:59:16 +0100
Mark J Reed wrote:
>What I'd like to see is a good generic Apple Events API that can be leveraged from any language you like
Um, there is: the Apple Event Manager. I'm assuming you mean a higher-level API than that, but it'd be difficult to get much higher in straight C - and C is, after all, the lingua franca for most languages' extension systems. It would be possible to do a pretty high-level API in ObjC, especially if you employ its more dynamic features to provide the sort of syntactic sugaring that appscript does, but that'd probably be even less convenient to wrap from other languages.
One additional service that Apple could usefully provide, however, is a simple C API to translate an application's human-readable keywords to AE codes and vice-versa at runtime. This is tedious, repetitive code for every language to implement itself, and since unlike AppleScript they invariably do all this work at runtime, performance and synchronisation issues add further hassles. Concentrating all this stuff in a single reusable C library would obviously be the best solution overall. Persuading Apple to do it may be a chicken-and-egg problem though, so such a solution will probably need to come from the OSS folks. The closest you can currently get is appscript's terminology server, but the API isn't very granular so clients still need to do some of the work themselves. My own C's not good enough to recast it as a comprehensive C library though.
>kind of like the DOM
Given that the Apple Event Object Model and Document Object Model are two distinctly different beasts - relational vs object-oriented - I'm not sure how much more functionality Apple could usefully provide in a lowest-common-denominator C API, given that C isn't particularly elegant at expressing either.
I'd much rather Apple just provided a set of written guidelines explaining in generic terms how one should go about wrapping the existing low-level C API in a high-level native API, but alas they don't and it's probably the main reason why most third-party attempts never quite seem to hit the mark without quite understanding why. This is why I've been writing appscript, BTW, partly to get Python's own IAC support up to snuff but also to provide a canonical model for other languages to follow when implementing their own equivalent support.
>and without waiting for Apple to implement language X for you, which seems to be the osascript model.
Nope, languages don't need to be OSA components to do application scripting, only to do attachability.
Implementing OSA support is IMO a serious chore due to lack of good documentation and guidelines, especially for developers who aren't already completely au-fait with OSA philosophy and culture. Still, it is crackable if anyone is really keen (Philip Aker's been making good progress on his collection of closed-source OSA components for a variety of languages, while I've made some headway on a comprehensive open-source OSA component though it really needs additional help to complete). OSA support is really icing on the cake though; providing really solid application scripting support is the big win.
Cheers,
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden