[Pythonmac-SIG] appscript terminology caching #2

[has]

Jack Jansen wrote:

>  > Disadvantages:
>  > - ATS must be running on every machine whose applications are being
>  > scripted (installation issues? permissions issues? add to startup
>  > items?)
>
>This I would consider a showstopper, specifically the "must" bit.

I don't think it's going to be that bad myself, but that's what we're 
here to find out, so onwards... :)


>There's all sorts of issues with starting daemons (like: will the
>daemon be system-wide or per-user?

It's a user-level process, so I guess that makes it per-user. Out of 
interest, does [Mac]Python run anything at any other level?

Question: what are the rules for Python.app? ATS occupies a position 
equivalent to that of Python.app, so presumably we can apply any 
rules for the latter to the former.


>What are the security-implications?

An important issue, and one I'm hoping other folks can tell me. :)

Thoughts: While I'm no security expert, I can't see ATS introducing 
any holes myself simply because it's so limited in what it can do. 
ATS's philosophy is effectively "Don't do anything your parents 
wouldn't do." Mostly it just performs tasks that are already 
doable/being done, though more efficiently. The only new behaviour it 
introduces to a system is the ability to request the terminology of a 
remotely running application, which it does via a standard channel - 
Remote Apple Events.

Now, RAE security is a system-level, not application-level, issue, so 
I can't see how ATS can do any damage there. Anyone who's breached 
your system security is going straight to Finder or Terminal to 
delete your hard disk, not ATS which has no facility for writing to 
disk or launching processes.

Therefore I'm feeling as confident as I can be not being a security 
whizz, but obviously would like some comment from those who are. I'll 
also sling this topic over to the AppleScript-Implementors list at 
some point; sound out folks there. (Particularly the Apple engineers 
who are presumably responsible for RAE and its attendant security 
issues.) I'll let you all know what comes of that.


>And what if different users have different versions of a program
>installed?

Don't understand this one; can you clarify?

(Note that the purpose of ATS is to return the terminology for a 
specified application. With local applications, the application is 
specified by path; with remote applications, by machine IP and 
process name. In either case, it's the user's responsibility to 
specify the right app; additionally, in the latter case it's the 
remote machine's job also to have the right app running. Neither is 
[fortunately] ATS/appscript's problem; they just take what they're 
given.:)


>Different appscript versions?

Pretty much a non-issue. ATS's Apple event interface is the only 
point of contact, and both it and the data formats it returns should 
be stable across versions.

The only thing that's likely to change is if/when Apple introduce an 
OSAGetAppSDEF call, which would affect ATS's planned 'get terminology 
[in raw form]' option. When that happens, we'll need a further option 
'get terminology [in raw form [using best available format]]' which 
would return a raw SDEF if the newer call is available and all 
parties how to use an SDEF, otherwise it'll call good old 
OSAGetAppTerminology to get and return a raw AETE (which is also the 
default when the 'best available format' option isn't included).


>So I would propose to make the daemon optional, and continue
>without caching if it isn't there.
>
>Hmm, maybe the search order for terminology should be the following:
>1. Check whether the developer has included precompiled terminology
>(which could be an option to py2app)

I think we should provide an optional 'terms' keyword argument to the 
app() constructor, allowing users to pass in an object containing the 
name-code translation dicts themselves (this seems the easiest point 
to add an 'in').

This would provide a penultimate fallback for users working with 
applications whose aetes are just too bolloxed up to work without 
manual patching, in which case the desperate user can dump() what's 
usable to file and replace the corrupted/missing bits by hand. For 
example, Smile's dictionary is a good example of this, lacking 
definitions for some basic commands and classes (AppleScript can use 
the default definitions from its aeut resource, but we're not 
AppleScript and want nothing to do with such kludgery), and 
forgetting to supply a keyword for at least one raw code. It would 
also bail out users who wish to use appscript to control a remote 
application on, say, an OS9 machine.

(BTW, since this wouldn't involve a custom file/module management 
mechanism as was being considered for the appscript-based caching 
system, it can use the standard Python module system so won't require 
special knowledge to use or tools like py2app to provide additional 
support.)

One other thing to note: let's not forget that users can always 
resort to using aem instead of appscript. I don't think it's 
appscript's job to bend over backwards to accommodate the few 
completely psychotic applications that spoil the air for everyone 
else. Appscript makes simple things simple; aem ensures that hard 
things are possible. AEM's API is deliberately unsophisticated but 
still designed to allow human use, and once you throw in some tools 
to auto-generate constants modules from aetes it should be a 
perfectly reasonable, if workman-like, option. Each tool to its own 
use.

Thoughts?


>2. Otherwise, check whether the ATS is running and obtain terminology
>from there

Easy enough for appscript.terminology to trap the MacOS.Error -600 
that occurs if ATS isn't running when it tries to call it.


>3. Otherwise do the whole generation yourself.

Trapping the above error and importing and calling the ATS 
terminologyparser module would add 4 lines to appscript.terminology, 
so wouldn't be hard to implement. This would only be good for local 
applications, however, and frankly, if you're allowed to run 
Python.app but not ATS then there's something a bit funny about your 
setup IMO. Being seriously anti-gratuitous feature creep, I'd still 
want some sort of justification for adding the extra rule. We have to 
balance the added complexity the extra search options introduces for 
the user: with an ATS-only solution they only have one rule to 
follow; more options means more rules to remember. (i.e. Don't forget 
the Python philosophy of "There should be one, and preferably only 
one, way to do it" - too many options can be worse than not enough.)

Many thanks,

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