The not-so-new trick has been to use AppleScript on the command line to not-so-harshly close some applications (run osascript, then tell application "program name" to quit, followed by ctrl-D (EOF).

The new trick is to sudo kill SecurityAgent, sudo run SecurityAgent, put the machine to sleep, then wake it back up (necessary to get SecurityAgent to put up a new password window).

Beyond that point, however, AppleScript was severely lacking in that the form in which that data was stored made it entirely unusable–AppleScript couldn’t convert it, couldn’t pass it off to an Objective-C method, etc.  As suggested in my previous post, there was a way around it, and messy though it was, I went about implementing that fix and by and large it worked (though it exposed another minor bug elsewhere).  But it really bothered me.

So I went back to looking at trying to integrate Python code into my tangled web of AppleScript and Objective-C, since XML-RPC is fairly easy in Python, though not quite as easy as in AppleScript.  And, eventually, I succeeded in integrating a class written in Python into the program (documentation on using the PyObjC bridge in this direction is woefully inadequate), using a less ineligant means of fixing the binary UTF8 data—

unicode(theResult.data,'utf-8')

(and Python also allowed me to generically recurse through the entire return structure, which wasn’t possible in Applescript).  Unfortunately, this version was substantially slower than the broken-Unicode version and not particularly any faster (perhaps slower) than the AppleScript-fixed Unicode version.

This led me to look for a way to do the XML-RPC stuff in Objective-C.  Now, mind you, the single thing that enabled me to even think about writing a client for LJ for Mac was seeing just how easy AppleScript XML-RPC calls were.  While I didn’t particularly want to try Python, the XML-RPC calls there weren’t that much harder.  But going to Objective-C for XML-RPC…  that’s a fundamental change in the program.  At least, to me.

I did a lot of Googling and found that there are actually a few XML-RPC frameworks for Objective-C/Cocoa (the one I used by Eric Czarny, the one from Brent Simmons, the Mulle one, XMLRPCObjC, SOPE).  Supposedly, there’s a way to do it with Apple’s own Cocoa stuff, but the documentation is woefully inadequate (none of the frameworks have amazing and wonderful documentation, but Apple’s documentation is bad) and almost every mention of it that I found on mailing lists and discussion boards said it was broken.  In the end, my framework choice was largely dictated by licensing, though there were also some issues with usability and dependencies.  As with AppleScript and Python, the UTF8 strings weren’t coming through as strings, but as NSData objects, which are fairly easy to convert with

[[NSString alloc] initWithData:theObject encoding:NSUTF8StringEncoding]

Recursing through the entire returned structure wasn’t particularly any harder in Objective-C than in Python.

The best part is that the resulting client with Objective-C-based-XML-RPC feels faster than the non-Unicode AppleScript-based-XML-RPC client.  In vaguely-objective tests (determine a set of steps that constitute a test and record the total time for just the XML-RPC calls in those steps, run the test several times under each app, compare times), the new version is measurably faster than the old version.

Bottom lines: (1) expect a new version of asLJ in the next few days, as soon as I get feedback from my early testers; (2) expect another post or two about other things I’ve learned in rewriting the XML-RPC aspect of asLJ in Objective-C.

This checks the class of the returned value and, if it’s a raw data object, attempts to cast it as text which raises an error, then extracts the string of hexadecimal values from the error message and puts it into a proper UTF8 object, making everything happy again.

If anyone wants to tell me I’m wrong and there’s a simpler fix, I’d love to hear it, since this is essentially unworkable.

tell application "<url>" to call xmlrpc ...

bits had to be hard-coded. That is, AppleScript didn’t like it when I tried to assemble the URL string on the fly. It took me a while to come up with a workaround, which should slightly impact the speed of the call, but doesn’t seem to make a noticeable difference. Here’s my generic handler for making LJ-based server XML-RPC calls:

aslj_client

aslj_users

(As it is very LJ-centric, most of the information about it will be over at LJ, in the two places linked above, but there is a page for it here, as well.)

On the Mac, however, I have tried several programs and never really been happy.  So I wrote a little AppleScript that not only sets up the SSH tunnel, but also deals with switching my location to set the system’s network settings to use the proxy (the code is after the cut).  Combine this with System Proxy for Firefox and all my application traffic goes through the SSH tunnel.  Note also that if you’re using a SOCKS5 proxy with Firefox, you probably want to set it to do DNS lookups through the proxy.

This script also stores the info for creating the tunnel (server, login, pw) in the keychain.

Here’s the “library” script where I put the functions to do the underlying work (since I have various different tunnels I use):

And here’s the actual script I run.