[Pythonmac-SIG] appscript terminology caching

[has]

Bob wrote:

>>Terminology resources belong to installed applications, not client 
>>scripts, so it wouldn't make sense to bundle it with the latter. 
>>(i.e. It's specific to a machine, not to a script.)
>
>I'm not sure I agree with this.

It's a matter of perspective.


>I'm pretty sure that compiled applescripts do not depend on the 
>terminology of the applications they talk to,

Correct: when an AS script is compiled, the AS compiler translates 
application keywords into raw AE codes. Thus compiled AppleScripts do 
not need terminology to execute. This was done for efficiency's sake, 
since AppleScript 1.0 was designed to run on memory-starved 16MHz 
Macs. It also explains why Apple never bothered to optimise the 
terminology system: they didn't need it to be fast because it's not 
normally invoked at runtime. There are tradeoffs in converting 
identifiers to AE codes at runtime, however - I can list the various 
problems with it if anyone wants.


>and I would imagine that the vast majority of applications written 
>in compiled languages that use AppleScript

[You meant 'Apple events', yes?]


>to talk to one another do not parse terminologies before they start talking.

Apps using the Carbon Apple Event Manager API won't use terminology 
at all, just raw AE codes. The Cocoa API doesn't support sending 
events, so that's academic, but uses terminology in Cocoa Scripting.

---

As a sidenote, something to remember here is that Apple events were 
deliberately designed to sacrifice ease of use for raw efficiency 
(binary encoding data, using 32-bit ints instead of human-readable 
names as keys, etc). Nowadays we can afford to burn some extra 
cycles, thus newer RPC mechanisms will encode data as XML, use 
arbitrary-length strings as keys and verbose mini-languages to 
construct references; Cocoa Scripting hides a lot of the Apple Event 
Manager's gnarliness beneath a terminology-driven layer; etc. In 
other words, there's no reason we must follow the same 15 year-old 
design compromises today, and it would be short-sighted to do so 
simply because "that's the way they did it". Remember, I came to 
Python precisely to escape from AppleScript. :)

---

>I don't think transparent caching should happen at all.

In a perfect world we wouldn't need caching at all: Apple's APIs 
would be comprehensive and fast (also, network latency would always 
be zero, pigs would fly, etc...).

This not being a perfect world, we use caching to compensate for its 
inadequacies. Now, from a usability POV, an ideal caching system 
_would_ be completely automatic, requiring no user interaction at all.

Again, this not being a perfect world, a 100% automatic caching 
system of the kind we're currently discussing is not possible. At the 
very minimum, remote application scripting requires that the remote 
application's terminology is manually created and locally cached 
since there's no way to retrieve it automatically across a network. 
So the sysadmin will have to do at least some work to keep things 
running smoothly.


>Caching should be entirely explicit, there's just too many problems 
>(having multiple versions of an application installed, write 
>permissions on cache, cache getting out of sync with applications, 
>client scripts written for version X of an application running on 
>another machine that has a version Y terminology cached, etc.)

Yes. Exactly the sort of real-world problems I'm struggling over, 
trying to see if there's any way to resolve some or all of them.

One note here: there are two _separate_ operations to consider:

1. adding terminologies to the cache

2. retrieving terminologies from the cache.

We already know that it's impossible to automate #1 entirely, but 
whether #1 is fully-manual/semi-automatic/fully-automatic has no 
bearing whatsoever on #2. Even if #1 were fully manual it could still 
be possible to make #2 fully automatic, and an automatic #2 would 
still have considerable worth from a usability POV since it would 
mean caching would remain transparent to the client scripts that its 
main beneficiaries.



>In other words, if implicit caching of AppleScript terminologies 
>made sense, Script Editor would do it.  It doesn't.

Like AppleScript, Script Editor doesn't do it because it doesn't need 
to. We, however, are neither AppleScript nor Script Editor. 
Fortunately. :)

Many thanks,

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