[Pythonmac-SIG] appscript terminology caching #2

[has]

Bob wrote:

>>>appscript can install the FBA into its package,
>>
>>Fine with me. I'm not sure how to package it for distribution 
>>though - AFAIK distutils isn't resource fork/creator code-friendly. 
>>Advice?
>
>It's not.  Don't use resource forks.

I've not. I do have a creator code though - makes it easier for 
appscript to identify ATS.


>You should be using py2app instead of bundlebuilder,

My eventual aim, yes.


>>>start it on on demand and just leave it running.
>>
>>This would work fine for scripting local apps; not sure about 
>>remote apps though (remote application scripting depends on the 
>>remote applications already being running). Is there a way to 
>>remotely start ATS running on another machine? If not, 
>>manually/automatically putting it in startup items and never 
>>quitting it is probably the best solution.
>
>This should be done explicitly.. it's a potential security hole, DOS 
>attack, etc.

Remote Apple events are just one huge hole waiting to happen. :)

Not sure that ATS introduces any holes of its own - can't think of 
any anyway. I think the assumption is that if you've turned on Remote 
AEs then you _want_ the machine to be remotely scripted, so if we say 
to users "you can manually add ATS to Startup Items" then we're 
probably covered.

Was responding to the suggestion that appscript could start ATS on 
demand: it can do this easily enough for a local copy of ATS used for 
local scripting, but for remote scripting it would need to start the 
local copy of ATS which would in turn need to start the remote copy 
before asking it for the remote application's terminology. i.e. A 
'start on demand' strategy isn't entirely straightforward, and a 
permanently running ATS might be the better option on balance despite 
having potential issues of its own.


>   Remote scripting isn't *that* common anyway.

True. Still, it's important that it work as smoothly as local 
scripting... which should work at least as smoothly as AppleScript, 
since that's what everyone is going to judge us against. It's the old 
problem of having to be at least twice as good as the opposition just 
to be acknowledged.


>>>Perhaps it should have a time to live of a few hours, and the 
>>>application terminologies probably should expire as well.
>>
>>Notes: ATS's terminology cache is in-memory, so will always expire 
>>when ATS is quit.
>>
>>Question: what would be the benefits of limiting ATS's running 
>>time, as opposed to just letting it run until system shutdown?
>
>Well if you're not using it very often, there isn't really any gain 
>to saving 0.5 sec once a day.

It's a slightly bigger saving that that, since there's also the time 
taken to fetch and parse each new application's terminology (~0.1-1.0 
sec each), but yeah, the advantage mostly comes from being able to 
quickly run the same script repeatedly in a session (e.g. during 
development), and having to rebuild the cache on a daily basis 
shouldn't cause noticeable pain.


>I often leave my machine on for weeks at a time, it just seems a lot 
>safer not to leave it running forever.

Yeah, you never know for sure what embarrassing things a really 
long-running program might get up to (e.g. leaving the memory taps 
running). I'd be happy enough for ATS to automatically shut down 
after a time - as long as we could find an easy way to get a remote 
ATS application back up again when needed. I really need to do some 
more research on this and am open to suggestions.


>>Another idea: would checking an application's creation/modification 
>>date be a viable way to avoid the cache going bad when a newer 
>>version of the app is installed in exactly the same location?
>
>For bundled applications you would have to walk the whole 
>application tree to see if anything has changed.. It's possible to 
>update resources without touching the outer folder.

Good point. Also, Steve's point that an application can gain or lose 
terminology as scriptable extensions are added or removed. Definitely 
puts the kibosh on that one.

How about process id? As in: "When ATS receives a request for an 
application's terminology, if the application's process id has 
changed since the terminology was last cached, reload it." Would that 
cover the updated application scenario okay? It won't cover the 
extensible terminology situation, but even that might be partially 
addressable, e.g. by having appscript request 'fresh' terminology if 
it encounters a keyword it's not familiar with.


Many thanks,

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