Via Ranchero, a list of Cocoa articles and resources.

As part of my exploration of using XML-RPC to script applications on OSX, I’ve written random people I’ve found on the ‘Net who might have some insight. After discovering applescript-implementors, I wrote one of the Apple engineers who I saw active on the list, asking if my questions were right for that forum. Chris Nebel responded, and gave me a lot of good information to chew on. I’ve simplified the thoughts I was developing after my last post on this and his comments in a series of pictures.

I want something that allows any script, in any language, to control any (scriptable) application running on OS X. Currently, I must use a language that speaks AppleEvents to script an application:

To open this up for languages that might not have the ability to send AppleEvents, I could write a service that acts as a “straight-through” for AppleEvents. This would allow a programmer to write something that looked and smelled like an AppleEvent in their language’s native tongue, and it would convert that into an Event more-or-less directly. While this would result in the functionality I desire (script OS X applications in any language), I don’t get any help. I have to use low-level messages to talk to the applications.

Furthermore, if I want to clump messages together to make my life easier, every single language I use will need that set of tools to be written. Now, I personally might not use a lot of different languages, but there are many languages out there, and I’d rather not have a solution that excessively favours one over another.

The tool blocks in the diagram above are programmatic tools. For example, there isn’t an AppleEvent that tells an application to open a file; this involves (I assume) a different combination of events for different applications. However, scriptable applications have a dictionary, that provides a reference to AppleScript programmers. AppleScript reads the dictionary, and finds out (I assume) what combination of AppleEvents are necessary (eg.) to open a file. Then, the AppleScript programmer just says something like (I don’t know one line of AppleScript, btw):

tell application "OmniGraffle"
   open document "foo.graffle"
end tell

And that’s it. That is what I mean by tools.

To achieve this effect, without forcing every language to have it’s own set of tools, requires me to move the tools into the service. If I’m really smart, the tools will be built so the way you talk to them is flexible; right now, I might want to use XML-RPC, but later, someone might want to use the same tools with SOAP, or they need to use HTTPS, or … who knows?

What you end up with is a language-neutral, high-level interface to scripting applications on OS X. My intuition was that this was doable–possibly very hard, but doable. Chris didn’t seem to imply otherwise, and this is the picture that he described and I was coming to on my own; it was good to know I was on the right track, and good to hear it from someone who understood all the pieces in the puzzle better than me.

So, when will it be done? I have a lot to learn about AppleEvents, dictionaries, and everything else surrounding the bottom layers of this picture before I can even begin contemplating writing anything in the upper layers of the cake. For me, this is a long-haul project. It’s interesting, challenging, useful to me, and probably mildly valuable in general. When it sits on the shelf, it sits; when it gets done, it gets done. In the meantime, I have a data to collect, analyses to do, and a PhD to finish.

This is just fun.

I’m getting obsessed with this.

First, I discovered the applescript-implementors mailing list at Apple; this is probably the community of people I want to join and ask questions of. I need to do some more reading, too.

That said, I did some sleuthing. OmniGraffle Pro has a file called OmniGraffle.scriptSuite in the Resources directory as part of the application bundle. This XML file clearly describes AppleEvents the application can respond to. Using Smile, I was able to get the AppleScript dictionary for OG Pro. I took a picture of the XML opened in the plist editor juxtaposed with the AppleScript dictionary.

If I understood what the AppleEvents in the XML file did, I could send them from MzScheme with using the sendevent.ss library. However, there is a clear difference in the level of abstraction provided by the AEvent and AScript interfaces. In an ideal world, an XML-RPC interface would be more than a thin wrapper for raw AppleEvents, providing the same level of abstraction as AppleScript.

One step at a time. I need to learn more about the whole OSA architecture, to start. I should also investigate the scriptSuite resource further; if it is a descriptor for the AppleEvents supported by a given application, I can certainly use that to automatically generate XML-RPC endpoints. Then, is it possible to programmatically build AppleScript level abstractions? Or, will it be up to the programmer to write a set of abstractions at the client-side? Perhaps Mac::Glue and it’s brethren will provide some inspiration there.

One of the people I asked to read my post on using XML-RPC as a bridge into AppleScript is the only guy I know who works at Apple, and we’ve only met once face-to-face. I think, however, we shared Oreos and played Formula De at the time, so that makes us much better acquaintances than you might think.

I can only challenge one part of his analysis: the XML-RPC library is much easier to write or come by than binding a new language to the Open Scripting Architecture. If I go the language-native route in Scheme, every implementation needs to have it’s own bindings. Although we call all of them Scheme, everything outside of the (tiny) standard can be different: foreign-function interfaces, module systems, libraries, etc. As it stands, several implementations already have XML-RPC libraries; only one has bindings for AppleEvents, and I don’t expect any others to follow suit.

Having to remember to run the service is a problem, but it is something that can be dropped in a Startup Items folder. And there are potentially serious security concerns with running a service like this. Either way, the analysis is good: my solution adds another piece in an already complex puzzle. The question, though battered, stands for the moment: is an XML-RPC bridge the “right way” to reduce complexity for the scripter in Language X, or does my proposed solution just add to it?

The Open Scripting Architecture is a nice bit of engineering, but it doesn’t make my life easier at the moment. To script an application on OS X, I have to use a language that supports the OSA: AppleScript, Javascript, Perl, Ruby, Python, UserTalk, or (arguably) Cocoa/Java. Objective-C and Java hardly count as “scripting” languages, but I’ll let that slide. The important thing is that I can’t sit down and script an arbitrary application in an arbitrary language, where arbitrary language means the language I want to use today.

If I want to communicate with an application under OS X, I get a limited set of data I can send at the application: Booleans, numbers of various sorts, strings, lists of these types of data, and values (record pairs, or a hash table, roughly). Because most programming languages support all of these types of data, you’d think I could script OS X applications from any language. Wrong!

I want to, though. Time for pictures.

Fig 1: Using the OSA to talk to an Application

I can talk to any application running on OS X using the Open Scripting Architecture (figure 1); this means I just have to use one of the languages that speaks OSA. I don’t want to use one of them, though.

Fig 2: Pushing a language through the OSA to get to an App.

I could “push” my language of choice through the OSA, somehow (figure 2). This seems… tedious. I could do that by adding OSA support directly to my language, by cross-compiling some or all of my chosen language into one that supports the OSA, or in the case of PLT Scheme, I could build on the existing AppleEvents facilities, which I could probably do if I put some more time into it.

Of these, my third solution is best: it leverages existing work, and relies on supported features of my language that I can trust to… well, I can trust to be supported. Unfortunately, any solution that ties me to one language (and, in the case of Scheme, one implementation of the language) doesn’t solve the real problem: I want to script any application from any language.

Next slide, please.

Fig 3: Using XML-RPC for cross-language communication.

I have, in the past, written programs that talk to each-other, even though they are in completely different languages. At IUB, I had a handy set of scripts that processed my research data on 60 machines simultaneously, using a combination of Scheme and Perl. I’ve also had cases where I’ve driven Java programs from Scheme; odd, but it was useful. Drop in a little web-server, an XML-RPC library, and I have cross-language communication.

After my post yesterday regarding OmniGraffle, I had a nice back-and-forth over email with the two members of the OmniGroup about this. We left it off with this solution:

Fig 4: A piece of software that converts XML-RPC calls into OSA events.

I should write an XML-RPC to OSA adapter (figure 4). This way, they don’t have to write any code, and if done right, my “black box” can act as an adapter for any application. This, I must admit, is true. And until I went on a walk into Canterbury this afternoon, I thought it was nothing more than a stopgap for the real solution. I had convinced myself that applications should have support for XML-RPC built in, as opposed/in addition to the OSA.

Fig 5: Using XML-RPC to script Applications

I realized this is wrong. And it is wrong for several reasons.

Fig 6: Problems abound if you push XML-RPC down to the App

–>

1. A lack of standards. Every single app will have a different API, and if I want to tell the application to open a file, I have to figure out what RPC endpoint I have to call to make it happen. It could be called openFile, open, fileOpen, or anything else.
2. A port number nightmare. If every application has a tiny HTTP server built in, I have no idea what port number they’re all on. And what happens when I have two apps that want the same port? Even if they sort themselves out, my script won’t be able to find the endpoint it’s looking for.
3. Incompatibilities. One XML-RPC implementation will support introspection, while another one won’t. One server will give proper HTTP error codes, while another one won’t. Every endpoint will have it’s own quirks, and it will be up to me, as a scripter and application developer, to keep track of all those quirks. That is bad.

So where does this leave me? If I add support for the OSA to My Favorite Language^TM, then only my language can make use of the new feature: I gain one more OSA-enabled scripting language. If I push it into the application, I end up with lots of problems: dialects, collisions, the works. The benefits are worth solving the problem: any language that handles XML and talks HTTP can drive an app in my proposed regime, and that’s a lot of languages. Being able to script one application on one machine from another machine is another win, which is something I think you can’t do with AppleScript (but I don’t know for sure).

While the black box, as drawn in figure four, seems to be in-between the applications, where I really need to think of it is below.

Fig 6: OSA is a system service

The Open Scripting Architecture is a system-level messaging service. Languages can patch into it to send events to applications. Client applications can register themselves with the service, and listen for messages destined for them. In this way, OSA is providing both an API for communication, as well as brokering communications between the scripter (regardless of language) and the target application.

If I want to have XML-RPC as a scripting interface to applications on OS X, I need to provide an XML-RPC service. It has to eliminate the possibility of port collisions, it has to eliminate my wondering what port any given application is listening on, and it has to guarantee consistency in the transport protocol and APIs as I move from scripting one application to another. OSA already does all of this, so I need to as well.

Fig 7: XML-RPC as a system service

Apple is not going to dump the OSA or AppleScript. I can’t get application developers to support yet another scripting interface—they aren’t going to make their apps “MCJ XML-RPC Service”-aware. So, I have no choice but to build on top of OSA if I’m going to leverage existing technology (OSA), keep track of where apps are (OSA), and interop with as many existing applications as possible (that use the OSA).

I do get a lot of things for free, though. I only need one server, and that server handles mapping all my XML-RPC calls to the appropriate AppleEvents. It can even pull apart target application dictionaries, and provide an introspection interface at the higher level. All of the hard work is done by the middle layer, and the scripter just makes calls against the new service.

I’m not saying anything here that hasn’t really been said already: Dave Winer, in his article Fractional Power HTTP Servers, said the same thing, but he didn’t push it all the way down—and if you don’t, it breaks. Or, at the least, the tedium and inconsistencies I describe plague every scripter everytime they want to script another application.

Punchline

References
I’m really, completely, 100% treading on well walked ground. This isn’t new.

1. The XML-RPC homepage (spec)
2. DaveNets on this topic: 1996.06.16, 1997.09.14, 1998.03.28, 1998.07.14, 1998.07.19, 1998.11.17, 1999.01.29, 1999.02.04, 1999.09.20, 2000.10.03, 2000.11.30… oh, you get the picture.
3. Tutorials and press related to XML-RPC.
4. OmniGraffle, a first-class diagramming tool for OS X.
5. Greg Titus, one of the cool people in the OmniGroup who didn’t tell me to zark off. Joel Page, Support Ninja Linebacker, cannot be directly referenced. Both are participants in the referenced, but invisible to you, email exchange.

I’ll provide some pictures and high-level info re: what I’m thinking later. For now, some resources for later reference.

• The AppleScript Sourcebook
• [ Scripting Glossary ]
  Definitions.
• [ MacPerl AppleEvent tutorial ]
  Good background info on AppleEvents and the underlying architecture, perhaps.
• [ Mac::Glue ]
  Ah. This could be a glue layer I could drop behind an XML-RPC server. Maybe? Also, the rest of Pudge’s MacPerl stuff and the MacPerl homepage.
• Following on the same thread, the CPAN pages for Mac::Glue. Of particular interest might be Mac::AETE::App, which “reads the Macintosh Apple event dictionary from an application”.
• [ The Open Scripting Architecture : Automating, Integrating, and Customizing Applications ]
• [ Carbon Specification for Open Scripting Architecture ], from Apple’s Developer Connection.
• [ Open Scripting Architecture Reference ]
  Might be the same information, but in HTML form. Also Apple Developer Connection.
• [ The Open Scripting Architecture : Automating, Integrating, and Customizing Applications ]
  Citeseer reference to the unpublished PDF I had referenced before.
• [ Using the Open Scripting Architecture from Python ]
• Design of a modern scripting language. A movie, actually, of a presentation.
• William Cook, managing technical lead of the AppleScript project back in 1993. Now at UT Austin.
• A list of links for developers working with AppleEvents and the OSA. Looks like they’re all dead, or behind a password protected FTP site.
• A DaveNet, March 23rd, 1998, laying out the conceptual base for what became XML-RPC. I echoed the same thing in my previous post.
• Apple’s AppleScript Developer’s page. Some of the links I have here are repeats from this page.
• Minotaur. Not because it’s related, but because it’s wacky. An embedded Forth system that allows evaluating Perl in Python, Python in Tcl, Tcl in Perl, Python in Perl, Perl in Tcl… oy.
• [ OSAShell Scripting Component ] OpenSource from Ranchero Software; OSA->shell scripting, although it might be something I want to come back to.
• F-Script. Open source. From their page:
  

  F-Script is a lightweight object-oriented scripting layer specifically designed for Mac OS X object system (i.e. Cocoa). F-Script provides scripting and interactive access to Cocoa frameworks and custom Objective-C objects. It aims to be a useful and fun tool for both beginners and experts, allowing to interactively explore, test and use Cocoa-based objects and frameworks.

• [ Embedding F-Script into Cocoa Applications ], O’Reilly.
• Mulle XML-RPC client/server framework for Objective-C. Cocoa XML-RPC client from Ranchero. And another library for Objective-C, from padl.com.

That’s it for me for the moment. Perhaps I’ll dig around through all of that over the next day or two and start thinking concretely about how to put this stuff together.

In short, I want an XML-RPC -> OSA bridge. It can be OS X native, because (well) there aren’t any other operating systems that support OSA. This means I can write it in any language I want, as long as I get cheap and easy access into OSA from the language I write the server in. This could mean a CGI written in Perl, using Mac::Glue, or it could mean a pure Objective-C/Cocoa app. For all I know, because of Java’s ability to use any of the NS* frameworks under OS X, I could probably write it in Java.