hengist.podd at virgin.net
Mon Jan 12 12:41:13 EST 2004
Michael J. Barber wrote:
>>>OSA and AEM are complementary, but distinct.
>This, more than anything else, seems to be the key point.
It's certainly an important start. :)
>>>(2) Making one or more convenient interfaces to the application
>>>"object model" for the programmer.
>>I think I get your meaning. To be a bit more precise: we write a
>>module that connects to the AEM. This allows the scripter to
>>manipulate an application's object model by calling the module's
>>This is what I'm doing: appscript is a Python-specific
>>implementation of a friendly, intelligent high-level API. The
>>generic API I'm designing will provide a common pattern for
>>developers on other languages to follow when implementing their own
>>high-level AEM interfaces.
>Yes, that is exactly what I had in mind. Programmers ideally get an
>interface that hides all the icky stuff and lets them focus on
>getting the application to do what they want.
AEM-to-<your language> bridge developers get a solid template to work
by. Scripters get an interface that provides them the full
flexibility of AEM with superior ease-of-use for doing application
control. And, as a bonus, application developers get a better idea of
what's expected of them when adding scripting support to their
>And, of course, multiple interfaces are possible.
Yes, in that the brickwork is always the same, but the choice of
finish (raw, painted, roughcast, or whatever) can be tailored to suit
each particular market.
>>BTW, I'm even wondering if it'd be worth doing an implementation of
>>the generic API in C/C++/Obj-C.
>That seems like a good idea. However, maybe there's a simpler
>approach that gives the same benefits? In AppScripting, you've
>already got a Python implementation of your high-level API.
Yes, albeit with Python-specific sugar already applied. (Though it
can always be returned to pristeen generic form.)
> Would it seem reasonable to leverage that work through a
>socket-based approach? That opens things up to essentially all
>languages fairly quickly, and still allows reimplementation in C if
>and when it becomes necessary.
Couldn't answer this without a quick lesson in socket-based
programming as it's something I'm not up on.
>>Dunno about you, but I think we're starting to make some damned
>>good headway too, all thanks to this thread. Pats on back all round
>>will be due at the end. <g>
>I certainly feel like the issues are clearer than they were a week
>ago. The discussions of this topic that periodically recur on this
>list do seem to be showing gradual progress.
Definitely. Though what'll be far more valuable is for Jack to write
up and post his 'eureka' moment. (Jack: that's a Big Hint, btw!<g>) A
single moment of pure blinding revelation like that is worth more
than a month of ordinary discussion, especially when we have to start
communicating what we've learnt to the community at large.
>Good interapplication scripting strikes me as a significant
>development, potentially even a "killer application," for whatever
>language gets it right first.
Perhaps. Though please note I have no interest in playing favourites;
having just escaped one appallingly partisan language, I've no
intention of creating another. ;p
Finally, realise that having a nice API for application scripting
solves only part of the problem: the real task is educating users
about it. There's a lot of entrenched mindset out there built almost
entirely on misconception and mistrust, and beating that is going to
take some doing. If Apple themselves can be persuaded to start
promoting Mac IAC and AppleScript as the separate technologies they
are, we could be laughing. OTOH, if Apple's marketing plans dictate
they continue to sell the two as one ('AppleScript' being a far more
powerful brand than an obscure bunch of cryptic TLAs, after all) then
be prepared for an uphill slog. I'll sound out Chris Espinosa shortly
to see which way they'll swing; we'll have a better idea of what it's
going to take after then.
p.s. I'm really starting to enjoy this. Wheeeeeeee!!!!!!!! <g>
More information about the Pythonmac-SIG