AppleScript_ The Definitive Guide - Matt Neuburg [210]
on test(m)
tell application "Finder" of machine m
set n to (get name of window 1)
end tell
display dialog n
end test
test("eppc://mattneub:teehee@duck.local/?uid=501") -- mattneub
test("eppc://mattneub:teehee@duck.local/?uid=502") --guest
The identical syntax allows you to target a different user logged into the local machine. In other words, if a machine has multiple users logged in, you can run a script under one user and target an application under another user. You can describe the present machine as localhost. Don't forget to turn on Remote Apple Events on your own machine!
tell application "Finder" to get name of window 1 -- mattneub
set m to "eppc://mattneub:teehee@localhost/?uid=502"
tell application "Finder" of machine m
get name of window 1 -- mrclean
end tell
XML-RPC and SOAP
XML-RPC and SOAP are web services . This means they are ways for one computer (the client) to query or command another computer (the server) over the Internet. The server defines certain commands to which it is prepared to respond. The client somehow knows what these are, and issues one of the commands with appropriate parameters; it also knows what sort of reply to expect, so it can parse the reply that it receives and extract desired pieces of data from it. If this sounds a lot like what Apple events and AppleScript are all about, it should! AppleScript is a good fit with XML-RPC and SOAP, and it makes sense that the AppleScript language should be capable of functioning as a client.
XML-RPC and SOAP do not themselves use Apple events for communication. They use the HTTP protocol. This is clever, because HTTP is the protocol you use in your browser when you type in a URL or click a link to ask for a web page. It's a common, well-understood, and widely implemented protocol. An XML-RPC or SOAP message can be sent anywhere that a web page request can be sent—because it is a web page request. And any CGI-enabled web server can function as an XML-RPC or SOAP server; it treats the message from the client just as it would an ordinary web page request—because it is a web page request. A message from the client to server is actually XML, structured according to certain conventions; this XML is wrapped up in an HTTP post argument (a post argument is the same sort of thing that gets sent when you press the Submit button in a web page form in your browser). The server looks at the requested URL and passes the message along to the appropriate CGI application, which pulls the XML out of the post argument, parses it, does whatever it's supposed to do, and hands back the reply. The reply is structured as a web page consisting of XML, so the web server just sends it back in the same way that it would send an ordinary web page back to your browser.
The web server here need not in fact be elsewhere on the Internet. It could be on your local network, even on the same machine. It isn't difficult to set up your own web server to function as an XML-RPC or SOAP server ; there are standard modules for doing this with Perl or PHP, for example. This means you can use AppleScript to communicate with a Perl or PHP script. I know someone who does this as a way of storing certain email messages in a MySQL database . PHP has a good interface to MySQL, so it makes a good intermediary. His email client is scriptable; when he receives an email message that he wants to store, he runs a script that captures the information from the email message and sends a SOAP message containing it to the web server running on the same machine; the web server processes the SOAP message through PHP, which stores the email message in the MySQL database. (For a similar architecture, with AppleScript speaking to Perl instead of PHP, see http://developer.apple.com/internet/applescript/applescripttoperl.html.)
AppleScript targets XML-RPC and SOAP services through support built into the Apple Event Manager.