[Pythonmac-SIG] appscript terminology caching #2

[has]

Ronald Oussoren wrote:

>>>Depending on how ATS works there could be other problem: there is 
>>>no reason to assume that user Jack started a real ATS. What if he 
>>>started a modified version of ATS that returns garbage?
>>
>>Then appscript will fail. But this would be true for any scriptable 
>>application. You can only use Remote Apple Events when both client 
>>and server can be completely trusted, otherwise it's a massive 
>>security hole.
>
>Fail in what way?

ATS returns a list containing five code-name translation tables in 
string format which the appscript.terminology module then parses into 
dicts for consumption by appscript.specifier. If appscript received 
anything else, the parser would choke. You can see these tables for 
yourself by running the following AppleScript:

tell application "AppscriptTerminologyServer" to «event ATSrTerm» 
"/Applications/TextEdit.app"


>>>What happens when two users are logged on at the same time (Fast 
>>>User Switching)?
>>
>>Don't know how FUS works, so hoping somebody else can tell me how 
>>application scripting, RAE, etc. work under it. It's a question 
>>that definitely needs answered.
>
>I'd hope that application scripting works in the context of one user session.

I've not turned up any info so far, but will try to find out.


>>>I don't like a hidden daemon, especially when it accesses the 
>>>network and can be accessed across the network.
>>
>>ATS [...] has no independent network access priviledges - it's 
>>merely a gopher for priviledged third parties.
>
>Ah, I hadn't noticed that ATS is only accessed using OSA.

Well, Apple events [1]. It's just a simple bundlebuilder-based app 
built using MiniApplication and aem.receive. Sorry if I wasn't more 
clear about this - I'll add an explanation of how ATS works to the 
documentation (soon as I get around to writing it).


>  I assumed that you communicated using some private protocol.

Oh, I'm far to dim and lazy to invent anything like that. ;)


>Most schemes that work for ATS should also work for a manual cache.

Sure, but the problem isn't whether the cache is file-based or 
in-memory; it's how much work the user has to do to maintain it. The 
objective is to have a system that provides appscript with 
application terminologies for both local and remote applications 
while requiring the least possible amount of user interaction and, 
ideally, providing the best possible performance. ATS does pretty 
well on both counts;


>>Except this creates extra maintenance hassles for the user, and 
>>we're back to having inferior application scripting support 
>>compared to AppleScript.
>
>py2app (or a gui wrapper around it) could automaticly perform the 
>maintenance hassles: You write a script that uses appscript, drop it 
>on "Build Py2Applet" and this scans your script for calls to 
>appscript.Application("iTunes.app")

That's almost exactly what the AppleScript compiler does when it 
looks for 'tell application "Some App"' blocks in source code to work 
out what keywords to use while parsing that block. It's a really 
smelly hack and a regular pain (e.g. it can't cope with stuff like 
'tell application nameStr' and 'tell applicationObj').

Also, we need something that works equally well in all situations, 
not just for py2app-based applications. A lot of AppleScripting is 
just quick, small, throwaway scripts, or typing and executing 
commands in an interactive text window/console if you're using Smile 
[2] or SD.

Using compile-time kludges to what's clearly a runtime problem is one 
of the things that's really wrong with how AppleScript implements its 
application scripting support. It's one of the things I specifically 
set out to avoid with appscript, so no chance I'd support it I'm 
afraid. :/


>>p.s. Here's an idea for an interesting side project if somebody was 
>>interested in pursuing it: an XML-RPC/Apple event bridge [...] that 
>>hooks a Python-based XML-RPC server to aem, allowing any language 
>>that speaks XML-RPC to control applications, and, unlike Remote 
>>Apple Events, is designed specifically for use in untrusted 
>>environments.
>
>regarding "untrusted environments": only when you add explicit 
>checks for security. If the server bridges to all of Apple events 
>you wouldn't get a more secure solution.

Yes. I suspect designing the permissions system will be rather more 
work than implementing the bridge itself.:) Perhaps a system that 
allows you to explicitly declare which applications you wish to 
expose and which commands and classes should be accessible? I dunno, 
but it's a tasty challenge for anyone that fancies taking it on.

Cheers,

has


[1] The term OSA refers either to a specific API used to build 
pluggable language components or an umbrella term for 
scripting-related APIs, which kinda includes AEM although it has 
other uses too. (Blame Apple for any confusion this causes.) Only 
thing appscript/ATS uses the OSA API for is the OSAGetAppTerminology 
function, which is kinda out of place even there.

[2] Incidentally, I really wish Python had something equivalent to 
Smile's text windows: a really nice implementation, perhaps as a mode 
on regular script windows, could pummel the older CLI-oriented 
interpreters into the ground, imnsho. Maybe something Glenn might 
like to look at?
-- 
http://freespace.virgin.net/hamish.sanderson/