Re: Tell Blocks Considered Harmful (was Re: open for access)
Re: Tell Blocks Considered Harmful (was Re: open for access)
- Subject: Re: Tell Blocks Considered Harmful (was Re: open for access)
- From: has <email@hidden>
- Date: Sat, 13 Dec 2008 14:40:31 +0000
Chris Page wrote:
1. You are proposing that osaxen are treated as individual
namespaces within AppleScript in the same way that applications
already are. This would do three things:
[...]
B. avoid osax commands being sent to any process other than the one
running the script
[...]
My own proposal is much more modest and basically an enhancement of
B: don't have processes handle osax commands at all; instead, let
the AppleScript interpreter handle them.
I'm not sure I understand how your proposal is significantly
different from a compatibility standpoint.
The key difference is that my proposal isn't about improving
AppleScript, it's about improving the rest of the OS. Apologies if
that wasn't clear before. Allowing process A to load arbitrary object
code into itself is to be expected; allowing process A to load
arbitrary object code into any other process isn't so wise from a
security/stability point of view.
To be honest, my proposal is largely orthogonal to Philip's, but since
we're on the subject of modifying the osax system it seems an obvious
time to bring it up.
Of course, it's up to Apple to assess the potential risk that the
current osax loading behaviour poses and decide what, if anything,
needs done about it. Yes, locking down osaxen this way will disrupt
existing AppleScript users a bit, but Mac OS has already been
embarrassed by one serious osax-related security hole this year and as
the platform's market share grows it's going to be increasingly
targeted by malicious parties. Given that the whole AEM/OSA system
doesn't seem to have changed its philosophy on security and
permissions since it was originally designed for use on the single
user, minimally-networked System 7 this might be a good time for some
fresh thought on the subject, and any remedial measures taken before,
rather than after, they become a physical problem for Mac users.
...
Shane Stanley wrote:
> Do you have any scripts or applications that intentionally send
scripting
> addition commands to other processes? If so, why?
I'd imagine the big ones among users are display dialog and the
other UI
commands (display alert, choose from list, choose file, choose folder,
choose file name), for obvious reasons.
And the clipboard's dictionary says in part: " Use in a tell¹
block..."
Yep, these are the ones I think are most likely to be affected as
well. e.g. There may be times when a script developer might want a
dialog to appear within, say, Finder, rather than the process running
the script. Though as said before, any inconvenience to AppleScripters
has to be measured against any risk to platform stability or security,
and in most, if not all, cases there are other ways to achieve
equivalent behaviours.
There have also been a couple of apps that have implemented part of
their
scripting through scripting additions -- QuarkXPress and Photoshop
come to
mind. In both cases I *think* it related to implementing coercions.
The Adobe one is; I can't recall the QXP one but I imagine you're
right. In any case, I don't think these osaxen should be affected,
since the coercion handlers they provide are basically intended for
AppleScript's use anyway. (If QXP and PS also need to use these
coercion handlers internally, they can install them themselves if they
don't already do so.)
The query I have with Hamish's proposal is with terminology
conflicts: at
the moment, the app wins, so you can use, for example, the word "read"
within FileMaker's scope for FileMaker's use, and still call the
scripting
addition by doing it outside the FileMaker tell block (or within a
tell
block to another app if the script is being run by Filemaker
itself); with
Hamish's proposal, it sounds like you'd effectively lose access to
any app
function that had a conflicting name.
Durr, you're right (I need my holidays). Scratch what I said about
commands within a 'tell application' block being sent to the internal
osax handler table first; instead, they need to be sent directly to
the target application, and only if the application returns a 'event
not handled' (-1708) error should AppleScript send them to the osax
table to see if they can be handled there.
I should also point out that the reason for this ungainly arrangement
isn't because it improves the language's design (it doesn't), but that
it allows all osax handling to be moved into the AppleScript component
while still preserving 99% compatibility with existing AppleScripts.
...
One last comment before I duck out of this thread due to other
commitments:
I'm not opposed to osaxen being completely namespaced *in principle* -
like I say, I really wish it had been done that way to begin with -
but *in practice* I believe it would be wrong to make such a change
now when the price is breaking compatibility with 99% of existing
AppleScripts [1].
As I say, there is no shortage small, cheap and completely non-
disruptive improvements that Apple could make to the AppleScript
language that will be of good and immediate benefit to its users (e.g.
a decent suite of text processing commands). OTOH, trying to undo
fundamental or deeply entrenched design flaws at this stage in its
lifetime would likely be money down the drain. Let's face it; if these
defects *really* represented a serious day-to-day problem for
AppleScript users, they'd all have dumped the platform years ago.
Clearly that hasn't happened, so it's fair to conclude that the
aforementioned flaws are quite liveable with, and trying to make
radical 'fixes' now is likely to harm users far more than it will ever
help them.
AppleScript will never be a 'great' language, but it can be 'good
enough'.
Best regards,
has
[1] Yes, okay, some bright spark might suggest kludging in 'use legacy/
transitional/strict mode' checkboxes/macros/whatever for toggling
osaxen scoping rules, but is that the sort of logistical crap you
really want clogging up a supposedly end-user oriented language such
as AppleScript? If I honestly thought that sort of thing would be an
improvement I would be the first to suggest it rather than advocating
for the status quo.
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden