Brent points out that there’s a non-trivial cost to supporting multiple kinds of weblogs in a blog front end tool like NetNewsWire or Manila Envelope. Weblogs may look alike on the surface (and to an RSS aggregator), but they’re all different software platforms underneath and accordingly have different information needs. This is fine as long you don’t have to expose the mess to the user.

This is one of the reasons, I think, why the MetaWeblog API came about. Abstracting the common elements of the data elements into a new API layer is smart. Unfortunately not all the platforms support it...

Sincere apologies for the temporary triple posts. It looks like I got false error messages from Manila Envelope making me think I had to repost. Ah well. Another day, another bug.

After the big release of 1.0.3a on Tuesday, a reader in England found some bugs I had missed in the first go-round with Manila Envelope on Jaguar. Specifically, people using the software for the first time can’t post!

The problem was a result of two things. First, the problem with Jaguar requiring plain text for XML-RPC extended into an additional function call that I hadn’t investigated, one that passed a URL as one of its parameters. This particular call only happens if no successful calls to the server have been made before, so I didn’t catch it in my haste to release 1.0.3a. Once again the importance of thorough testing...

Second, I made a big fuss about the importance of separating user interaction from business logic back in February, but didn’t catch all the problem areas. This particular problem was caused by a function that returned a string value. In the first implementation, I had the calling functions make the assumption that an empty string meant an error had occurred. Only problem: if the calling function in the UI is handling error notification and I’m returning a single empty string parameter, there’s no way to provide detailed error information.

This is where I miss “pass by reference” in other programming languages. It then becomes simple: you pass in a variable to be transformed by the method, and you check a return value for success or failure. Instead, I am using multiple return values:
return {true, callResult}which means I have to use AppleScript’s copy syntax instead of a simple set. Ah, growing pains.

The release notes are here. This version adds Jaguar compatibility. It has not been tested with pre-10.2.1 versions of Mac OS X; feedback is appreciated. Also noteworthy: this version now uses XMLRPC exclusively. You can download the software here; source code is also available.

I’ve deliberately avoided adding new features in this release since it took me so long to get the Jaguar bugfixes figured out. But there may be a couple of new features coming soon.

A while back after installing Jaguar I found that Manila Envelope no longer worked, or worked only intermittently. I upgraded to 10.2.1 last night, and I don't know if this has anything to do with it, but it worked again--for about two minutes. I posted two test posts successfully to the editing region, but now it's not working at all.

Did Apple break something in 10.2? I'd love to know. One possibility is the new Core Foundation web services framework, which has probably been shimmed under the existing AppleScript SOAP support introduced in 10.1 (at least, that’s how I'd do it). Another possibility is that something broke in the CFString search and replace functionality that I use to do fancy text processing. Debugging it is really really painful.

At least I have wireless. I had forgotten about my Wayport membership. My flight takes off in another hour or so, and I can't wait. It'll be the first time all week I've had any sleep.