On 3 Dec, 03:41, John Joyce <dangerwillrobinsondan... / gmail.com>
wrote:
> On Dec 2, 2007, at 8:12 PM, Giles Bowkett wrote:
>
> > I think this is one reason Apple's getting behind Ruby w/RubyCocoa,
> > etc. I could be wrong, though.
>
> >http://developer.apple.com/scriptingautomation/overview.html
>
> > "Scripting Bridge, new in Leopard, brings advanced automation to the
> > desktop, making it easy to send Apple Events--the built-in messaging
> > architecture of Mac OS X--between applications, allowing you to
> > leverage the features of rich desktop applications from your own code.
> > The best part is that your code can be in the language you want,
> > whether Objective-C (with Scripting Bridge), Python (with PyObjC),
> > Ruby (with RubyCocoa), or pure AppleScript."
>
> > I read somewhere or got the impression somehow that the whole plan
> > here was to leverage the power they built into AppleScript but allow
> > people to use languages they actually *enjoy* using, so Apple could
> > stop sinking money into AppleScript and instead leverage the hackery
> > and energy of the open source communities around Python and Ruby (and
> > others).

All the real functionality is at the OS API level (Apple events, OSA)
and in the applications that leverage these APIs to expose some or all
of their functionality to other programs. AppleScript is just one of
several client languages for these services (it wasn't even the first,
btw; UserTalk predates it).

As for Scripting Bridge, I'm rather disappointed with it myself: it
lacks several features found in AppleScript, is noticeably inferior on
the application compatibility front, parts of its API are badly
designed or basically unfinished, and the lack of native APIs on
Python and Ruby makes those languages feel like they're being treated
as second-class citizens in the AppleScript world. Still, that's why
there's appscript. :)


> I too wonder if Apple is or isn't cooking up some kind of appleScript  
> replacement.
> Ruby would be wonderful candidate for it.

I wouldn't mind seeing a full-blown OSA language component for Ruby
myself, which is what you really need to replace AppleScript 100% as
that'd let you use Ruby for tasks that require attachability (Mail
rules, folder actions, etc).

However, I believe Ruby's internal architecture makes this difficult
as it doesn't ensure that unrelated scripts hosted within the same
Ruby runtime are 100% isolated from one another. I've already run into
similar problems designing my PyOSA component, which is why it's still
not got past the 'developer preview' status after more than two years;
well, that, and I'm lazy. (One solution might be to host each Ruby
script as a separate subprocess, but the OSA wasn't really designed to
work that way so this is likely to cause other problems, not to
mention an inevitable performance hit.) Still, if anyone wants to
discuss this topic further, drop us an email.


> But maybe too wonderful...?
> The trouble with Apple Events is that in order to really make use of  
> them, you have to know a lot of Cocoa stuff already.

You don't have to know any Cocoa stuff to use Apple events; however,
you do have to know at least a bit about how Apple events work, and
quite a lot about how individual applications implement their Apple
event interfaces. The latter in particular are notoriously
underdocumented which can cause some real headaches when learning to
script a new application, requiring you to fall back on a mix of
intelligent guesswork, trial-and-error experimentation and shared
community knowledge to figure things out. Though hopefully as more
folks are introduced to application scripting via Python, Ruby, etc.,
application developers will start to take scripting interface
documentation and other issues more seriously.

HTH

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org