[Pythonmac-SIG] appscript terminology caching #2

[Ronald Oussoren]

On 26-okt-04, at 0:27, has wrote:

> Ronald Oussoren wrote:
>
>>>> Depending on how ATS works there could be other problem: there is
>>>> no reason to assume that user Jack started a real ATS. What if he
>>>> started a modified version of ATS that returns garbage?
>>>
>>> Then appscript will fail. But this would be true for any scriptable
>>> application. You can only use Remote Apple Events when both client
>>> and server can be completely trusted, otherwise it's a massive
>>> security hole.
>>
>> Fail in what way?
>
> ATS returns a list containing five code-name translation tables in
> string format which the appscript.terminology module then parses into
> dicts for consumption by appscript.specifier. If appscript received
> anything else, the parser would choke. You can see these tables for
> yourself by running the following AppleScript:
>
> tell application "AppscriptTerminologyServer" to «event ATSrTerm»
> "/Applications/TextEdit.app"

I finally download appscript, but haven't looked at the code yet.

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?

>
>
>>>> What happens when two users are logged on at the same time (Fast
>>>> User Switching)?
>>>
>>> Don't know how FUS works, so hoping somebody else can tell me how
>>> application scripting, RAE, etc. work under it. It's a question
>>> that definitely needs answered.
>>
>> I'd hope that application scripting works in the context of one user 
>> session.
>
> I've not turned up any info so far, but will try to find out.
>
>
>>>> I don't like a hidden daemon, especially when it accesses the
>>>> network and can be accessed across the network.
>>>
>>> ATS [...] has no independent network access priviledges - it's
>>> merely a gopher for priviledged third parties.
>>
>> Ah, I hadn't noticed that ATS is only accessed using OSA.
>
> Well, Apple events [1]. It's just a simple bundlebuilder-based app
> built using MiniApplication and aem.receive. Sorry if I wasn't more
> clear about this - I'll add an explanation of how ATS works to the
> documentation (soon as I get around to writing it).

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.

>
>
>>  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 
:-)

>
>
>> Most schemes that work for ATS should also work for a manual cache.
>
> Sure, but the problem isn't whether the cache is file-based or
> in-memory; it's how much work the user has to do to maintain it. The
> objective is to have a system that provides appscript with
> application terminologies for both local and remote applications
> while requiring the least possible amount of user interaction and,
> ideally, providing the best possible performance. ATS does pretty
> well on both counts;

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.

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.

>
>
>>> Except this creates extra maintenance hassles for the user, and
>>> we're back to having inferior application scripting support
>>> compared to AppleScript.
>>
>> py2app (or a gui wrapper around it) could automaticly perform the
>> maintenance hassles: You write a script that uses appscript, drop it
>> on "Build Py2Applet" and this scans your script for calls to
>> appscript.Application("iTunes.app")
>
> That's almost exactly what the AppleScript compiler does when it
> looks for 'tell application "Some App"' blocks in source code to work
> out what keywords to use while parsing that block. It's a really
> smelly hack and a regular pain (e.g. it can't cope with stuff like
> 'tell application nameStr' and 'tell applicationObj').
>
> 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).

>
> 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?


Ronald