I wish to access iTunes app through my ruby script and looking at all the 3, I am confused which one should I go for. Seems like Appscript is not being supported anymore http://appscript.sourceforge.net/ hence am thinking to remove it off from my options list. Am left with Scripting Bridge and custom AppleScript (make my own script).
After reading online about the flaws and poor documentation, I am confused with which should I start?
Experienced users please suggest which could be the best or if there is any other scripts which could be helpful.
Thanks!
I've done all three, but from Objective C as the calling language, instead of ruby.
AppleScript. You can write and call an AppleScript from ruby using osascript. AppleScript has great support in terms of interactive development using AppleScript Editor. This works very well. But...calling through osascript is cumbersome, and you're invoking an extra process every time you talk to iTunes. You also have to parse the output of osascript -- not a huge deal, but definitely taking you away from what you're really trying to do.
Scripting Bridge. That leaves Scripting Bridge and appscript. Scripting Bridge has the benefit of being official Apple-supported code. Scripting Bridge has its warts, but it definitely works, and the tooling support is good. However, I don't know how you'd integrate that with ruby -- someone else may want to comment there.
appscript. Appscript has good docs and a strong rep as a superior bridging solution. Matt Neuberg has moved appscript over to github (https://github.com/mattneub/appscript), explicitly with the goal of using the ruby portion of that project. Another fork (https://github.com/abarnert/appscript/network) adds further fixes, and that's where I would start. I myself (https://github.com/poulsbo/appscript) have brought the Objective-C up to date (circa Xcode 6 beta 5), but I haven't touched the ruby side.
Scripting Bridge vs. appscript. One difference I've noted between appscript and Scripting Bridge, from a user's perspective, is that appscript is more explicit (good) but also more verbose (not good). Here is an example (pseudo-Obj C) of getting the name property of an object; you explicitly do a get and send:
id result = [[[appscriptObject name] get] send];
Whereas in Scripting Bridge there's an implicit lazy evaluation, so it looks more like:
id result = [sbObject name];
There's also a different treatment of type information in the generated headers. I believe Scripting Bridge retains better type information.
Appscript seems better about error handling, e.g. telling you when something isn't available. With Scripting Bridge, you seem to get an object regardless, and upon using it, you have to query it afterwards to see what the lastError was. I find that coding pattern to be ugly.
Backward looking? All that being said, the problem, as you point out, is that appscript is probably best seen as "backwards facing technology." If you adopt it, you're looking at supporting/fixing any problems in appscript on your own, or relying on fixes from others. Although it seems to work well today (OS X 10.9), in the future you can expect it to break or need further maintenance to keep it running. On the flip side, since you have the source, you can fix problems on your own. A bug in Scripting Bridge is going to be out of your hands.
If you want to flip that around and be forward looking, you might want to check out what Apple is doing for Yosemite with JavaScript as the new OSA language. However, that gets away from your original question, which is about ruby and iTunes.
Bottom line. Various tradeoffs here.
AppleScript. Playing it safe.
Scripting Bridge. A nice middleground? But not sure how to use from ruby.
appscript. For the hobbyist/DIY person.
JavaScript. For the early adopter.