Bill Bumgarner: Radio Commentary

It appears that system.verbs.builtins.html.getFileURL() breaks if your Radio installation is on a different volume than the system. In particular, it is failing to encode the volume name into the file:/// URLs.

RadioService v1.0a1 is now ready for download. This version fixes a number of bugs and streamlines the implementation. It also adds the rest of the post related Blogger API functionality; get, get recent, edit, and delete. The hot key to create a new post has been changed to "|" (a post?) and, as such, should be available in more apps most of the time. All functionality is available to non-service aware apps by manually filling the pasteboard (i.e. select some text, press copy), selecting the appropriate functionality via the RadioService's dock menu, and then manually posting the result. As such, RadioService functionality is now available to Classic applications. The documentation (i.e. ReadMe) has been mostly rewritten (again) and should be better than before. Select the 'RadioService Help' menu item from within the app to view the ReadMe in your favorite browser.

Sweet... just implemented 'getRecentPosts'. If used as a service, it retrieves the last five posts. If used via the dock menu or from within the app, it parses the contents of the general pasteboard as a number and retrieves that many posts. The posts are dumped in a format that [shortly] is directly consumable by the editPost service to edit a particular post. Cleaned up some of the code, as well.

Riddle me this; escaping in xmlrpc According to the xmlrpc spec and the implementation within Frontier/Radio, you are not supposed to escape anything in a <string></string> typed param or return blocks other than '<' and '&'. However, every implementation of XMLRPC in a client library that I have run into-- python's xmlrpclib, Mulle Kybernetik's frameworks, and AppleScript's xmlrpc call-- escape a bunch more characters. In every case, the set of characters escaped is different. So, who is right? In my case, 'right' is defined by what works in Radio because that is what I'm testing against (and actively using, more or less). The 'extra' characters that were escaped were the source of all the annoying & and ' stuff in the posts. (Currently on the road: posting this to my weblog at 30,000 feet on the way to Miami. That's one very distinct advantage to Radio-- even when completely disconnected, I can still actively work with my weblog in both an authoring and development role. It is the only reason why RadioServices was written in the first place. I'm sure there are other products capable of this, but $40 and a cactus is good enough for me.)

RadioService v0.9a3 is now ready for download. No new features, just works better-- see previous post regarding encoding of characters. You can pretty much select any hunk of 8 bit content from anything and post it via the service without worry that you'll have to diddle the quotes and other characters in the Radio desktop interface. As the application has all necessary frameworks embedded within, the download jumped from 50k to 280k. Anyone want to submit a custom Aqua Styled icon for this thing? (Still haven't fixed the request-caused-app-to-launch-so-it-doesn't-post problem. Not sure what is up with that. Now that the silly character encoding stuff is [hopefully] gone, I'm going to focus on features and tweaks.)

OK-- if this post works, it is because:

RadioServices is now using the Mulle Kybernetik frameworks (instead of AppleScript Studio's implementation of xmlrpc).
I figured out how to build the frameworks such that they can be included in the app wrapper, but do not have to be copied during development.
RadioServices now handles-- does not URL/HTTP encode-- various random bits of punctuation like "'<>'" while also handling escape sequences like <>"'& (these should be rendered as the sequence).
RadioServices now logs on console when something bad happens (personally, I would like a little more feedback for services, but this is currently The Apple Way).

The rest of the world is under the impression that more characters than just '&' and '<' should be encoded for string params in XMLRPC. Not so, according to the XMLRPC spec or the Radio UserLand implementation. AppleScript Studio encodes at least the various quotes and the Mulle-Kybernetik framework encoded a lot of things before I patched it. I submitted my patch back to the maintainers. The response was that all of [< > & ' "] should be encoded. This is certainly the behavior of AS Studio, but runs counter to Radio and the Spec (as I interpret it). If anyone has a clue, please share. Code has been checked into the repository. I'll try to get a disk image out tomorrow before I'm off to Miami for business. (geez, I download build 44 of OW and not but five minutes later, build 45 shows up. Thank goodness for a fat pipe.)

This is a test of punctuation handling. !@#$%^&*()_+=-{}|][:"';<>?/., (Worked like a charm. Patches submitted to the appropriate parties.)

The following is taken straight from the XML-RPC specification.

What characters are allowed in strings? Non-printable characters? Null characters? Can a "string" be used to hold an arbitrary chunk of binary data? Any characters are allowed in a string except < and &, which are encoded as < and &. A string can be used to encode binary data.

Go to the page and compare the contents.... I can't decide if all of the problems are with the encoding passed through the XML-RPC framework I'm using or if this is a bug in Radio's internal XML-RPC handler [method param decoder].

Jim Roepcke sent me an email that through some weird free association in my brain, caused me to fix a memory smasher in RadioServices. I'll clean it up and push a new version out the door sometime soon.

ow That hurt. I rebuilt the hard drive on my TiBook a couple of days ago; actually, I replaced the 20gb Toshiba drive with a 48gb IBM drive that has a 5400 RPM spindle speed (vs. the Toshiba's 4200). Between that and defragmenting the drive, my TiBook is a boatload faster now. Nice. In the process, I moved to using two partitions. This changed the name of the drive Radio lives on as well as the path to the application. Radio does not handle this situation gracefully, at all. Andy Fragen wrote a neat little script that fixed most of the path references in Radio. However, it didn't fix all of 'em. I still had to hunt around and fix a few dangling references to the old hard drive in Radio.root (and, maybe, weblogsData.root). I'm not sure exactly what, but things mostly seem to work now. Help images are still broken. This situation sucks. The fact that you can't move Radio Userland or even change the name of the hard drive it is on makes the whole thing rather fragile and un-Mac like. Why can't there be a variable or two that point to the root of the Radio Userland directory and have everything else derived from that root?? *sigh*

That last post was a test to see how hard it would be to change frameworks. This post is a test to see how hard it would be to refactor RadioServices such that it has all features of version 0.9a2, but uses the Objective-C XML-RPC implementation (which, incidentally, adds a tremendous amount of 'in case of bad things' feedback to the user).

!@#$%^&*()_+=-{}|]['";:/?.>,<

Ahhh.... much better. Everything you type into, say, TextEdit arrives in Radio without any quoting stupidity. Seems that AppleScript's XML encoder is a little overeager in quoting apostrophes and quotes.

I moved to using a pure Objective-C implementation of XML-RPC. Totally kick butt implementation; it was actually a reduction in the # of lines of code when moving from AppleScript's xmlrpc to their implementation! Not only that, but the application now automatically gives useful error messages when the targeted XML receiver is either not running/responding or is up, but refuses the request.

Let me repeat myself: Cocoa, Foundation, and Objective-C kick major ass.

Expect a new release of RadioServices in the next day or two...

Well, almost. Little help buttons are broken, but I can live with that for the moment.

OK-- assuming this post actually makes it through, then Andy Fragen totally rocks! I just rebuilt my OS X box [a TiBook] -- upgrading to a 48gb IBM HD in the process -- and the paths to my Radio UserLand environment are completely different. Radio feature request: ship with Andy's script built in and easily accessible... make it automatic, at that.

When access is turned off for a particular host and you submit an XMLRPC request from that host against the Radio server, it responds with an XML body that contains error information, but the response itself is marked as 200/OK. Maybe this is the correct behavior in teh XML world? In any case, it causes hell from AppleScript because it doesn't seem to be possible to grab the raw response body itself (that I can figure). AppleScript definitely generates an error, but it seems to be totally generic-- i.e. there is no way to recover the response body and see what is really going on (or provide feedback to the user).

A couple of Radio related issues; It seems to be impossible to require Radio to use authentication when talking with the localhost. Why would you want to do this? Imagine you were working in a computer cluster on a network account. It is likely someone could ssh into the machine running Radio and, because they are on the localhost, do anything they want to your Radio desktop either from the command line or, if they are feeling particularly evil, by port forwarding 5335 to 5335 on their own machine and using a full blown browser. Also, it isn't 100% clear if it is possible to require a username/password to access the XML-RPC/SOAP interfaces *at all*. I can restrict access via hostname/ip address, but that doesn't help if I want to be able to communicate with a remote Radio environment in a fashion that doesn't open it up to everyone the subnet (or, at least, anyone who happens to log into the machine I'm using).

RadioService v0.9a2 is available for download.

Post from pasteboard via Dock Menu works (for non-services aware apps)
automatically open radio desktop and edits new post (can be disabled via preferences)
can automatically fire any URL you want after successful post
major code refactoring; cleaner implementation, but still far from ideal
rewrote README, now includes Radio configuration instructions
README can be accessed from in app by selecting 'RadioServices Help' menu item.

There is still a bug where RadioServices will work correctly for the first post when the post request caused the app to launch. Every post after that works, though. Not sure what is up with that. The next step is to get remote posting to work.

Fixed a problem with the commit mentioned earlier. It is really committed now.

In the day after the release of RadioServices, I have been amazed at the response. It seems that most folks with a single desktop Radio based installation have had no problem. There hasn't been much feedback outside the Radio community, but there hasn't been any attempt to push it beyond Radio (since it was created to solve an immediate need I had with Radio). Some of the most frequently asked questions and answers (from someone whose knowledge of Radio is fairly shallow). Most all of the links assume Radio is running on the local desktop. How should Radio be configured to work with RadioServices (or apps such as BlogApp)? You need to make sure that the XML-RPC interface is enabled. Then, enable the the Blogger API. When RadioService asks for my password, which do I use? On this page, you will find a list of Radio password. Likely only one labeled default. Whatever that password is, that is the one you want to use. If you happen to have forgotten it (I did-- you create it when you first download Radio, 30 days before the $40 commitment decision), go to the Setup page and use the Forget your usernum and password? form to have your password sent to you. Does RadioService work with remote Radio applications? At the moment, likely only if you turn off all secuirty and enable full remote access. Obviously, a less than ideal situation. I have to figure out how to deal with the authentication issue from the XML-RPC engine in AppleScript (if possible). If not, I'll toss AppleScript and use Java instead. Will RadioService work with non-Radio based systems? Sure. Absolutely. Because I have never tried it, I can say with complete and utter confidence that it will work just fine because it is all about standards and nothing but standards. It should work fine save for the whole HTTP authentication stuff.

I just committed the changes discussed in previous posts to RadioServices. I will cut a new binary as soon as I figure out remote posting issues (which, hopefully, will not be too hard). In any case, the source should build without a problem on any OS X box with the december dev tools installed. (Still does not process the first post if that was the one that caused the app to launch. I wonder why.)

<>'";:[]}{.,/?!@#$%^&*()_+=-| The text above was created by typing '<>'";:[]}{.,/?!@#$%^&*()_+=-\|' into TextEdit and selecting the RadioServices 'Post to Blogger' Service. Radio Bug: I have to type '\\' to see a single '\' in the blog (which meant I had have to type '\\\\\' and '\\' to yield the aforementioned sentence...) This is what actually passed across the wire from AppleScript's xmlrpc interface to the Radio desktop server: <string> <>'";:[]}{.,/?!@#$%^&*()_+=-\| </string> (You don't even want to know what that looks like when entered into Radio) So, it would seem that the apostrophe-- the '-- is the only problematic character. It would seem that Radio does not want it escaped, but AppleScript escapes it. Honestly, I have no idea who should win.

Carbon & Services As Jim says, it is not a bug... it is a feature. Carbon apps have to write code to specifically enable the services menu. BBEdit has (no surprise), most-- including Word and IE-- have not. Bummer. I'm going to see if I can workaround the problem by providing a means to quickly post-from-clipboard. Easy enough; all the support is already in the app. It is just a matter of figuring out the quickest way to activate the functionality. Some folks are having problems interacting with remote Radio installations. I'm not sure what is up with that. If you have it working, please contact me so I can gather info from a working environment (but I will try to duplicate the conditions on my home LAN at some point). (And it made me a liar-- I can't directly use Word as an editor... I have to copy/paste somewhere else)

If this post works, it is because I have successfully imported the source to RadioService into MOSXLand, checked it back out, built and ran the application. Assuming it did work, you can check out a copy of the source by doing this:

% cvs -d :pserver:anonymous@cvs.mosxland.sourceforge.net:/cvsroot/mosxland login
(Logging in to anonymous@cvs.mosxland.sourceforge.net)
CVS password: ***no password-- just hit return***
% cvs -d :pserver:anonymous@cvs.mosxland.sourceforge.net:/cvsroot/mosxland checkout RadioService

New features since the 'release'; earlier today:

Preferences panel now works.
Option to automatically open radio desktop and edit the new post (useful for categorization of posts)
Some code cleanup, but not much.

Oddities: The code isn't pretty and there is some silliness/laziness. Please feel free to ask questions. The biggest items on the TODO list are to fix up the error handling and to improve/ensure interoperability with other Bloggers. As well, fixing up some of the cosmetic issues-- quotes are being escaped for some reason, for example-- will go a long way to improving usability.

Jason Gillman calls this a "Major Breakthrough!" How about a screen shot for us Mac-deprived people? --- The above was selected and posted via RadioService from OmniWeb. Here's the screenshot of the posting process. The services menu is automatically generated based on the various services advertised by the applications installed on the system. A service is advertised by what pasteboard types it can consume and what pasteboard types it produces. There is another mechanism called a 'filter service' which can automatically filter from one data type to another. Example: If you write an app that can only consume GIF images and I write a filter service that convert JPEG and TIFF to GIF, your application will automatically be able to open JPEG and TIFF. OS X rocks. Currently, RadioService only consumes NSStringPBoardTypes (that is, pasteboards that contain straight string data). This will change as the app evolves. <% radio.macros.imageref("/images/RadioServices.jpg", alt:"RadioServices in action")%> (No, I have *no idea* how that incredibly cool fadeout effect happened on the menu. Seems to be some weirdness associated with the Quartz Compositor and taking screenshots.)

It Works!!! RadioServices.app now:

uses defaults to store your configuration
uses the system wide keychain to store password(s)
automatically queries for a password, when needed (or to unlock keychain)
listens for keychain events and stops asking for a password if password is supplied via some other app

At this point, the app is useful to anyone running Radio in that the stored defaults work fine with a local Radio desktop. Since it asks for a password via the GUI (using code recycled from SSHPassKey) and stores the password in the key chain, the fact that it totally lacks a GUI for editing the defaults isn't a big deal. As such, I'm going to go ahead and post a version. (This was composed in WebObjects Builder for a sort of WYSIWYG HTML editing experience.)