[Pythonmac-SIG] appscript terminology caching
hengist.podd at virgin.net
Thu Oct 14 19:14:30 CEST 2004
First, a quick update: just posted appscript 0.7.1, which fixes a
couple minor bugs:
I've also added a dump() function to appscript.terminology which
parses and stores an application's terminology as a Python module.
This will be used by the terminology caching system I'm planning for
0.8.0, something that's required for remote application scripting 
and should also allow users to reduce the time it takes to create new
'app' objects by caching terminology data in advance.
Now to business: I'm looking for suggestions on how best to implement
this caching system. I've no clear idea on how to proceed with it, so
am throwing the thing open to discussion.
- Ideally the cache would operate constantly and transparently,
automatically caching an application's terminology the first time
it's used, and loading cached terminologies from disk by application
name and version number. A fully automated cache may not be
practical, however, in which case the user would need to manually
trigger the caching process and/or explicitly instruct appscript when
to load a cached terminology.
- Terminology modules may be generated on the machine where the
application resides and copied onto the machines that will remotely
control that application.
- The less user scripts are tied to a specific machine, the better.
If the user has to add machine-specific code to their script to load
terminology for a remote application (e.g. the terminology module's
name), that may be acceptable as such scripts are already less than
100% portable due to the presence of network-specific eppc addresses.
Breaking portability would not be acceptable in scripts that use
cached terminologies simply to improve startup time when scripting
local apps, however - such scripts should work regardless of whether
terminology comes from a cache or direct from the application.
- Any other way it could be done better? e.g. Run a 'terminology
server' daemon on each machine that supplies appscript with all its
terminology needs? Such daemons could maintain terminology caches for
local applications, and serve terminology data across networks upon
demand so that remote clients don't need to maintain their own
terminology caches for remote apps. Can't hurt to toss around ideas
at this point.
- Usability and reliability are essential, and portability would be a
- Also, some other poor sap may have to maintain the appscript code
some day, so KISS as much as possible.
- Last thing I want is a clumsy Glue-style system.
- Remote scripting support is already implemented in aem for those
that want to check it out.
1. Is there a universal and foolproof way to get an application's
version number? Particularly when that application is running
2. If not, how else could an application be uniquely identified? URL
or full path are options, though paths may change, applications may
be updated in-situ, copies of the same application may exist in
multiple locations (e.g. if InDesign 3.0.1 is on a dozen networked
machines, it'd be better to have a single terminology module that
works with all of them than have a dozen identical modules, each one
tied to a different location), and multiple versions of the same app
may exist on a single machine.
3. How and where should terminology modules be stored?
4. How should terminology modules be [uniquely] named when created?
How should they be located and loaded for use? Can this be done by
filename/directory structure alone, or would it need a central index
to locate modules by application name, version,etc?
5. If a fully automated cache isn't possible, what would need to be
done manually and how?
6. What all could go wrong?
Please post your thoughts, suggestions, criticisms, etc. This is the
second-to-last major task I'm facing (the last is writing full
documentation), so the sooner it's solved the sooner I can get on
with kicking the damn thing out the door at last. :)
 OSAGetAppTerminology doesn't work across networks, so a remote
app's terminology needs to be sourced locally.
More information about the Pythonmac-SIG