RubyOSA vs. rb-Applescript
R.B. Love
over the other?
Does Ruby OSA have some quasi official status?
matt neuburg
> Does anyone have a comparison of the two? Any reason to prefer one
> over the other?
I like RB-Appscript, mostly because I think the author is so
knowledgeable about AppleScript. m.
--
matt neuburg, phd = ma...@tidbits.com, http://www.tidbits.com/matt/
Tiger - http://www.takecontrolbooks.com/tiger-customizing.html
AppleScript - http://www.amazon.com/gp/product/0596102119
Read TidBITS! It's free and smart. http://www.tidbits.com
has
> Does anyone have a comparison of the two? Any reason to prefer one
> over the other?
Short answer: Appscript is significantly more powerful, robust and
mature than RubyOSA.
...
Longer answer, starting with a quick rundown of notable differences:
- Appscript fully supports all object model reference forms, including
element-by-range and element-by-filter. RubyOSA supports property,
element-by-index and all-element forms, and little else (even the
initial 0.1.0 release of py-appscript managed more than this).
- Appscript has better Ruby<->AE type mappings, e.g. RubyOSA's
typeAlias/typeFileURL<->string mappings lack meaningful type
information and don't roundtrip properly.
- Appscript has a better command syntax with proper support for keyword
parameters. RubyOSA munges them into positional parameters, which is
less elegant and robust.
- Appscript has a more open, flexible design based on a well-defined
three-tier architecture: Appscript, AEM and AE. (RubyOSA is
single-tier). All three APIs are available to clients (though the
low-level AE API is currently undocumented). e.g. Applications that
don't have dictionaries (or their dictionaries are significantly
broken) can be controlled via the AEM API.
- Appscript "gets" Apple events and the Apple Event Object Model, and
merely spreads a bit of syntactic sugar over their RPC+query semantics
for readability. RubyOSA tries to squeeze those "weird" semantics into
a narrower, rigid object-oriented mindset (the result feels more like a
COM bridge than an Apple event bridge). Some queries that work fine in
appscript and AppleScript will never work in RubyOSA because of this.
- Appscript is a lot more forgiving of real-world application bugs and
quirks, and imperfect or broken terminology. The current architecture
has had a pretty good real-world shakedown over the last two years,
with fixes and workarounds for both common and obscure application
compatibility problems being incorporated as users have uncovered and
reported them. RubyOSA relies very heavily on application dictionaries
and assumes they're both completely comprehensive and 100% correct, so
tends to trip up any time they're not. (Early versions of appscript
were also pretty strict, btw, but that approach was dropped after the
first year due to the compatibility problems this caused.)
- Appscript supports scripting additions and remote Apple events;
RubyOSA doesn't.
- Appscript has reasonably complete documentation. (Both have tools for
displaying application dictionaries, of course, but only appscript
includes documentation on the bridge itself.)
- Rb-appscript 0.3.0 is now only a code review + tech edit away from
official beta status (volunteer reviewers needed, btw!); RubyOSA 0.2.0
is "still under heavy development".
What it basically boils down to is this: Appscript is a very mature,
capable and well-proven solution. It's already established itself as
the de-facto application scripting solution on Python after beating out
the two previously existing projects: gensuitemodule and aeve. In fact,
py-appscript was originally created out of dissatisfaction at the
approach those other two solutions were taking. Similarly, rb-appscript
was started out of dissatisfaction at the approach RubyOSA was taking.
Six months on from its first release, RubyOSA 0.2.0 is still less
functional than py-appscript 0.1.0, which was written in under a month.
And rb-appscript 0.1.0 was a direct port of py-appscript 0.16.0, so
even though rb-appscript is technically less than half the age of
RubyOSA, in reality it has a huge three-year lead over RubyOSA in terms
of research, design and real-world testing.
The RubyOSA website claims that it allows you to do in Ruby whatever
you could do in AppleScript, but this is only [mostly] true under the
loosest interpretation of "whatever". Whereas appscript actually does
(caveat one or two very minor differences in capabilities and
behaviour); as Matt says, I'm pretty much an expert on AppleScript and
client-side Apple events so when it comes to beating AppleScript at its
own game I know how to hit my marks.:) If I'm being very optimistic I'd
say that given another six to twelve months and a strong wind behind
it, RubyOSA might eventually come within 80-90% (about the ceiling
limit imposed by RubyOSA's design philosophy) of what appscript can do.
But right now it's still very much at the discovery (a.k.a. "learning
by your mistakes") stage and nowhere close to being the mature product
that rb-appscript, despite its deceptively low version number, is
today.
> Does Ruby OSA have some quasi official status?
RubyOSA is written by the Apple engineer responsible for the Ruby
installation included in Mac OS X, and Apple hold the copyright on the
code itself, so I imagine the answer is probably yes. :)
That said, Apple do seem to take some interest in the third-party Apple
event bridges as well, e.g. they included Mac::Glue in Tiger and
currently provide appscript with Mac OS Forge, so take that for
whatever you think it's worth.
Hope that helps, and if you've any more queries then just fire away.
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
Robert Love
> R.B. Love wrote:
>> Does anyone have a comparison of the two? Any reason to prefer one
>> over the other?
>
> Short answer: Appscript is significantly more powerful, robust and
> mature than RubyOSA.
>
> ...
>
> Longer answer,
[deleted]
Thank you for that comparison. It was the sort of thing I was looking for.
And Matt, thank you also.