Re: AS Library Question
Re: AS Library Question
- Subject: Re: AS Library Question
- From: has <email@hidden>
- Date: Thu, 17 Dec 2015 23:49:34 +0000
On 17/12/2015 14:30, Chris Page wrote:
On Dec 11, 2015, at 3:02 PM, has <email@hidden> wrote:
Yeah, I've been banging on for years about the need to replace OSA with an out-of-process architecture for loading and running scripts for precisely the same reason.
So, like, NSUserScriptTask. There you go, right?
The right thing would be for Apple to deprecate NSAppleScript...
You're conflating orthogonal concepts. There's no need to disallow running scripts in the current process just because there's a mechanism for running them in another process. They're complementary, layered facilities, one built upon the other, and each has its use-cases.
NSAppleScript is lame and crippled and does nothing that can't already
be done via OSAKit (though that also has its problems, most notable a
total lack of public documentation). More importantly, the entire Mac
Automation stack is utterly bereft of focus or direction - and has been
for years. Like a long- and sadly-neglected Apple tree, a *really*
vigorous hack-n-slash would actually do it the power of good.
AppleScript (and OSA) is a rich, powerful technology for solving many different kinds of problems, many of which either require that scripts run in the client's process or perform better there. Your use-case of running a standalone, arbitrary user-supplied script is only one of many.
For example, many programs use embedded script languages as part of their core functionality, either to run built-in scripts or user-supplied scripts that extend or modify application behavior (c.f. Lua). AppleScript--and, more generally, the OSA technology--was designed primarily for this, from the start.
Except *nobody else* provides OSA components except Apple. Partly
because in-process hosting is totally inappropriate for most
Unix-evolved scripting languages; mostly because there's less than a
dozen people on the entire planet who have even half a clue how to do
it, never mind are interested in doing so.
After 20-odd years, the message really should have gotten through @Apple
by now: the OSA component system is a *failed* technology. It simply
doesn't matter if it was the most perfectly-designed,
perfectly-implemented technology ever (which it isn't) if nobody's
actually using it. Which they aren't. Those of us who have tried and
eventually figured out how to do it have ultimately abandoned it,
because implementing OSA components for most popular languages *sucks*.
Making OSA officially legacy would at least open the way for a modern
successor to be developed, one built for the realities of modern OS X
and iOS where the priority is to ensure safety and stability through
sandboxed subprocesses, with developer-friendly XPC Services APIs
providing simple, high-performance inter-process glue.
In fact, that's what AppleScript applets are: they're an application whose behavior is almost entirely defined by a script (or scripts).
Mate, you're preaching to the choir. I've spent more time spelunking
Apple event and CM+OSA APIs than just about any other poor mad sod
alive. I'm fully aware of how awesome the original *concept* is. I'm
also painfully, pragmatically aware that the technology as it now exists
is *dead in the water* - that in 20-odd years nothing that third-party
developers have done has succeeded in changing this, and everything the
Automation team has done has only reinforced its technical and popular
failure further. Now I'm simply pointing out you've been sitting on a
giant crap-pile for so long, you no longer even smell it yourselves. Not
that I realistically have any more hope of change than the last
half-dozen times I pointed it out.
...and direct app developers to use ASOC for running its own internal scripts...
Hmm? “use ASOC *for* running internal scripts”? Did you mean something like “don't execute user-supplied scripts within your application process if they use ASOC” and “only run ASOC scripts inside your application process if you wrote them”?
Nope. I mean running AppleScript code that is part of the .app itself.
There's an infrequent but still relatively steady trickle of requests on
Stack Overflow (http://stackoverflow.com/questions/tagged/applescript)
from developers who need their app to send a command or two to an
"AppleScriptable" process such as Mail or iTunes, and the way they do it
is the same way they've been doing it (badly) for the last ~15 years: by
munging an NSString into something resembling AppleScript source code
(almost invariably unsanitized, of course), then using NSAppleScript to
compile and execute the thing. Usually they get stuck on how to get data
in or out, or can't figure why it doesn't seem to be working, so they
post to SO which I still lurk on and occasionally respond by pointing
out other answers are wrong (which they often are too) or at least far
from ideal.
In theory, of course, those devs should really use the ScriptingBridge
framework to build and send Apple events directly from ObjC, but that
assumes 1. they're aware that ScriptingBridge exists (many aren't), 2.
they can figure out how to use ScriptingBridge (the API is lame and
nasty, with little documentation and even less examples), 3. they can
figure out how to control the target process (also with thoroughly
inadequate documentation, and what examples exist are invariably written
in AppleScript), and 4. after all that effort, Scripting Bridge doesn't
simply up and shit on their request, with zero explanation why (since it
a horribly obfuscated, fundamentally broken, POS).
So for the last few years I've just been telling ObjC developers to to
ditch NSAppleScript/SB and use AppleScriptObjC as a bridge to call FROM
Objective-C INTO AppleScript. (i.e. The opposite of how ASers use it,
which is to call from AppleScript into ObjC.)
There are some annoyances, natch: atrocious lack of official
documentation, no bridging for C primitives (you have to box and unbox
those yourself), and the usual caveats about ASOC not being what you'd
call industrial-strength software (but what in AS's world is?); but on
the whole it works pretty well. Unlike NSAppleScript, it's much quicker
and easier to use and does [almost] all of the heavy lifting for them,
and unlike SB allows them to write their IPC code using AppleScript
(which, while they hate as a language, is at least relatively well
understood and actually works right), and call it from ObjC as easily
[almost] as any other ObjC method. I even posted a quick HowTo after I
got tired of penning fresh answers every time:
http://appscript.sourceforge.net/asoc.html
Very bare-bones to say the least, but probably still worth bookmarking
in the absence of any official Apple documentation.
has
_______________________________________________
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