[Pythonmac-SIG] appscript terminology caching #2

[has]

Ronald Oussoren wrote:

>But I have a new question anyway: how do you ensure that you get the 
>right version of ATS? What if the user has installed appscript 0.8 
>and I create a py2app-ed application containing appscript 4.2, will 
>this start both ATS-es or just one of them?

Right now, deciding which application to launch when you've multiple 
instances installed is the OS's problem. You've the same problem when 
you've multiple versions of any app installed. I can't mind what the 
OS's rules for resolving these situations is (most recently 
installed? newest version?); anyone else know? At any rate, there's 
not much point in launching multiple versions of the same app since 
how will the Apple Event Manager know which one it's meant to use. 
ATS's interface should be stable by appscript 1.0.0 with the 
exception of its SDEF support; we can't implement that until Apple 
does, obviously.:) To prevent conflicts, we could even register the 
revised version under a different creator type.


Damn good question though: how will appscript/ATS behave in 
[semi-]standalone Python-based applications, which are responsible 
for supplying and managing their own dependencies rather than using 
the system-installed Python and maybe even installing the required 
modules into it if older or no existing versions are found?

It shouldn't really matter if there's a copy of ATS on the system 
that happens to get used instead, as long as that version isn't 
lacking functionality needed by the application or its own version of 
appscript. (Which is unlikely, though you can never be 100% sure.)


I think this can be framed as a general question: how does a 
bundlebuilder/py2app/any other kind of application deal with having 
sub-applications hidden inside the application bundle; how do they 
launch them and communicate with them, and avoid conflicts with other 
versions of themselves? This surely can't be the first time anyone's 
ever had to do this sort of thing, so there must be answers to it 
somewhere.


>AppleScript, Apple events, OSA, ... makes my head spin. I guess we 
>should be gratefull that Apple at least designed the system in such 
>way that we can write scripts in multiple languages.

Apple events - a high-level, serialised message-based interprocess 
communication mechanism

Open Scripting Architecture - 1. an API used to implement swappable 
scripting language components, and, in applications, to load and 
execute scripts written in any of those languages; 2. a group name 
for all of the Mac OS's application scripting-related technologies 
[note: Apple could have avoided a lot of confusion here if they'd 
called the API something like 'Scripting Component Support' instead]

AppleScript - 1. a simple scripting language with built-in support 
for constructing and sending Apple events, implemented as an OSA 
language component; 2. a misnomer for Apple event-based application 
scripting, as used in phrases such as 'AppleScriptable application' 
[note: also Apple's fault for conflating the two technologies in 
their marketing and other literature]

See also 
<http://www.cs.utexas.edu/users/wcook/papers/AppleScript/AppleScript95.pdf>

[I should probably post this summary on the pythonmac.org wiki for 
reference, but it seems to be getting overrun by scuzzball spambots 
right now so hardly seems worth it. Damn shame, but it's probably 
time it went subscription-based like the python.org wiki.]


>>>  I assumed that you communicated using some private protocol.
>>
>>Oh, I'm far to dim and lazy to invent anything like that. ;)
>
>and I wouldn't have dreamt of writing a scriptable application for this :-)

It just seemed an obvious choice. Daemons/FBAs seem a common solution 
when you've lots of short-term processes requiring some kind of 
support over a long period of time (e.g. cron), as are distributed 
applications when you've a job to perform that's spread across a 
network. And scriptable FBAs are an absolute doddle to write; while 
rewriting MiniAEFrame as aem.receive, I couldn't believe myself how 
little code it takes to handle Apple events (the real complexity is 
in evaluating Object Specifiers against an application's object 
model, but since ATS doesn't have an object model this isn't a 
problem).


>ATS only does well with remote scripting if you install ATS on the 
>remote system. This means automatic terminoligy retrieval for remote 
>scripting with appscript will work only in some situations.

To be precise: appscript can _only_ be used for remote scripting if 
it's installed on _both_ local and remote machines. (Though bear in 
mind that remote scripting will generally be used between trusted 
machines on a LAN and chances are these machines will all be 
administered by the same person/people, so this may not be a big deal 
for them.) It's a burden, but so is having to serialise each 
application's terminology on the server and copy the resulting files 
over to each client machine (something that would probably need to be 
done manually), as is grabbing the terminology from a locally 
installed copy of the same application (AppleScript's similarly 
less-than-satisfactory solution).

We have to accept that no solution we come up with will be perfect. 
This is all Apple's fault, after all, for providing sorely inadequate 
APIs, and all we're doing is putting a band-aid over it so we can 
stay in the game.


>As I said before cache maintainance shouldn't be an issue: a 
>file-based cache could use the same heuristics as a memory-based 
>cache to decide when to refresh the cache.

Right now the only refresh heuristics ATS uses is "manual reset" 
(which includes restarts). :)

I agree that caching for efficiency can be reproduced as a file-based 
cache, and could provide an equivalent manually initiated "rebuild 
cache now" command. That's the easy half though; figuring out a way 
for a file-based - or any other - system to get the terminology for a 
remote application is the hard half. And _that's_ the problem I 
couldn't solve except by switching to a distributed application-based 
solution, but if you can find a way to reproduce ATS's remote 
scripting benefits without recourse to such a system then go for it.


>>Also, we need something that works equally well in all situations,
>>not just for py2app-based applications. A lot of AppleScripting is
>>just quick, small, throwaway scripts, or typing and executing
>>commands in an interactive text window/console if you're using Smile
>>[2] or SD.
>
>Sure, but you don't need a cache *server* for that. A python IDE 
>could maintain an in-process cache. For most people that would be 
>good enough (tm).

I don't use an IDE; all my scripts get run in pythonw. So it wouldn't 
be good enough for me, for starters. :)


>>Using compile-time kludges to what's clearly a runtime problem is one
>>of the things that's really wrong with how AppleScript implements its
>>application scripting support. It's one of the things I specifically
>>set out to avoid with appscript, so no chance I'd support it I'm
>>afraid. :/
>
>The real solution would be to nag Apple to improve the performance of
>the OSAGetAppTerminology API :-).
>
>Any chance for you adding an API that would allow others to write 
>their own cache?

I'm going to add a 'terms' argument to the 'app' constructor, and put 
the dump() function from 0.7.1's appscript.terminology module into 
the new version. That's really so folk have a fallback option with 
applications whose aetes are too broken to work without manual 
patching, but you could just as easily subclass 'app' to use your own 
custom terminology management system.

...

So anyway - by all means go experiment; this is certainly the ideal 
time for it. Spend some time comparing AppleScript and appscript, 
particularly in terms of performance and usability, since AppleScript 
is the baseline we have to beat at least. Get some experience in 
doing application scripting if you've not yet done much/any. ATS is 
the best solution I've managed to come up with myself, but I'd be the 
first say there's a lot smarter folk in the world than me, so maybe 
they can maybe do better. Just mind that it's not enough to solve 
only one part of the problem; y'gotta come up with something that 
equals and/or betters ATS all round. Best o' British! :)

Cheers,

has

-- 
http://freespace.virgin.net/hamish.sanderson/