[Pythonmac-SIG] appscript terminology caching #2

Bob Ippolito bob at redivi.com
Thu Oct 21 14:27:44 CEST 2004


On Oct 21, 2004, at 5:11, 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.
>
> I've not. I do have a creator code though - makes it easier for 
> appscript to identify ATS.

Your creator code should be declared in the PkgInfo and Info.plist 
files.. BSD copying sure won't screw up text files.

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

That sounds like a good idea.  Actually.. you could register for all 
application start/termination notifications and get/parse terminologies 
for any application that starts.  You should be able to do this with 
PyObjC via NSWorkspace: 
http://developer.apple.com/technotes/tn/tn2050.html

-bob



More information about the Pythonmac-SIG mailing list