From: has Date: 2007-12-05T01:35:08+09:00 Subject: Re: Identifying a volume as being an iPod On 3 Dec, 03:41, John Joyce 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