• asLJCore is the primary component of the LiveJournal client asLJ, managing all communication with the server.
• YDDecode is a Cocoa class wrapped around some public-domain C code for decoding data encoded with YEnc.
• NCIDStatusBarMenu is a utility to help pull NCID-based callerID notifications and display them as Growl notifications (among other things).  I’d been meaning to update it for nearly 2 years with no success and the future isn’t looking much better, so I’m releasing the source instead.

(My musings on licensing below the cut.)Permissive BSD/MIT licenses because in writing asLJ among other things, I’ve had to work to find libraries, frameworks, components, classes, etc., that weren’t GPL-licensed so that I could continue to choose how I wanted to release my software.  I am also heavily influenced by the simplicity of the BSD and MIT licenses compared to the lengthy GPL (and while the LGPL ought to be workable for many libraries, I couldn’t quite wrap my head around the language of it–the LGPL is several paragraphs of modification to the GPL).

(The song lyrics and commentary for OpenBSD4.3 have a lot to do with how I feel about GPL versus BSD/MIT.)

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.)