[Pythonmac-SIG] appscript terminology caching #2

[Bob Ippolito]

On Oct 20, 2004, at 18:46, has wrote:

> 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.  What do you need them for?  
Bundlebuilder doesn't preserve resource forks either.  You should be 
using py2app instead of bundlebuilder, though it doesn't preserve 
resource forks either.

>> 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 scripting isn't *that* common anyway.

>> 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?
>
> Own thoughts: the longer ATS stays alive, the more benefit is gained 
> from caching (good) though there's also more risk of the cache growing 
> stale (bad). Regarding automatic expiry of cache: ATS could easily 
> flush individual entries in the cache after [e.g.] 48 hours even if 
> the application itself stays permanently running.
>
> Then again, periodically flushing the cache is probably a bit 
> hit-or-miss affair as far as keeping it in-sync with an application; 
> sure as guns users will update their apps precisely 30 minutes after 
> ATS last reset its cache and 25 minutes after they last scripted those 
> apps.:) Possible memory leaks aside, ATS also shouldn't impact much on 
> system memory since each cache entry is just a few KB. What other 
> advantages would there be to auto expiry of cache?

Well if you're not using it very often, there isn't really any gain to 
saving 0.5 sec once a day.  I often leave my machine on for weeks at a 
time, it just seems a lot safer not to leave it running forever.

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

-bob