[Pythonmac-SIG] appscript terminology caching #2
hengist.podd at virgin.net
Thu Oct 21 11:11:29 CEST 2004
>>>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.
>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
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
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.
More information about the Pythonmac-SIG