Cook Computing

Oh dear, techno weenie also has problems with a poorly defined spec leading to conflicting implementations:

Over the last few weeks, Ive been dabbling in an application using OPML. But, its been frustrating at times. The spec seems so thrown together, that every app seems to have its own version. Is the url given in the url or htmlurl attribute? What different types can there be for an outline node, and how should an app handle them?

There seems to be a common theme emerging here...

Fairly old items now but I notice Simon Fell had some problems with the XML-RPC blogging APIs:

... unfortunately no two bloggerApi / metaWeblog API implementations seem to work the same way, or even use the same message structs, but you already know this, I'm not the first (and won't be the last) to rant about that. I live in hope that the rounds of discussions of a soap based blogging API result in something more concretely defined.

Followed a couple of days later by a piece on Slightly Uniform Interfaces:

There's a lot of power in uniform interfaces, for one, it means I can write a single tool that should work with any server that implements that uniform interface. In reality, it seems that the various XML-RPC based blogging API's are slightly uniform interfaces, all the implementations are kind of the same, but different, for example, Moveable Type doesn't implement metaWeblog.getCategories, Radio's implementation of blogger.getUsersBlogs doesn't return a blogname value in the response. In metaweblog.getRecentPosts, Radio and MoveableType return different types for the userid value. I have an even greater respect now for the number of different webloging tools that NetNewsWire supports.

Finally, he decides the RESTLog API is a better alternative:

I've switched the blog over to a RESTLog API style implementation I whipped up in. NET, I could battle the metaWeblogApi no longer.

Just over two years after the first release of XML-RPC.NET, I've sorted out some hosting for the library's website. I've owned the XML-RPC.NET domain name since early 2001 but I only had it configured to forward all requests here.

But from now on the home page for XML-RPC.NET is www.xml-rpc.net.

I'm planning to set up a weblog at the new site for any interesting XML-RPC-related items I come across, XML-RPC.NET announcements, etc.

Scoble has an entertaining piece on an alternative Linux strategy for Microsoft. I'd personally like a Linux sub-system on Windows, i.e like Interix or whatever it is called these days. No more Linux installation hassles, dual-booting, or worrying whether Linux will run on the laptop you're going to buy. One possible drawback: the GPL might mean they also have to supply the source code for Windows. But didn't I read somewhere that they're planning to do that anyway for half the world's population, because the Chinese government will only endorse an OS for which the source code is available?

Chris Double commented on my last entry, asking why I think the current weblogging APIs are amateurish. Brad Wilson added another comment suggesting that the poor documentation and lack of nonASCII support are the problems. Here are the reasons for my opinion.

I find it amateurish that it is difficult to determine exactly what is supported by these APIs. Just because something is designed for a scripting environment (the often touted reason why typing in XML-RPC APIs can sometimes be vague) doesn't mean it has to be imprecisely defined or not defined at all.

I find it amateurish that the blogging APIs do not take account of the fact that XML-RPC, according to its spec, does not support non-ASCII characters in string values. Does Dave Winer, the inventor of XML-RPC, expect people to limit their blog entries to US-ASCII characters when using MetaWeblog? If he does, then MetaWeblog is a crippled API. If he doesnt, what is the XML-RPC spec worth? The professional approach here would be to encode strings in some way which was valid according to the XML-RPC spec, for example using the base64 XML-RPC type. (Or work on a way of transitioning XML-RPC to full Unicode support, but that is another story.)

I find it amateurish that as soon as I tried to develop a blogging client I came across omissions from the APIs. For example I wanted to be able to work offline, creating new entries and editing existing entries, and then resolving any conflicts with the server when I went back online. But there is no way of determining which entries have changed on the server since the client last connected to it. The only solution is to use brute force and download every entry and check its content against the locally cached data. Not very elegant. Similarly I wanted to know whether entries have been published since the client last connected. It is not clear how I can achieve this even if I download all the entries associated with the blog. These are the sort of requirements that any professional developer would have identified very quickly on doing some analysis, for example using Use Case scenarios.

I find it amateurish that the type of the postid item changes from API to API and from implemention to implementation. For example the MetaWeblog RFC suggests it should be a string but when you look at the sample request it is an integer.

I find it amateurish that there seems to be confusion as to what the description field is used for in MetaWeblog. According to the MetaWeblog RFC this field is designed to hold what the Blogger API describes as "content" but, also according to the RFC, description is taken from the RSS 2.0 spec where it is described as "The item synopsis". Movable Type addresses this confusion by adding a new item called mt_excerpt.

I posted the previous entry to Movable Type via the XML-RPC based MetaWeblog API. It was sad to see that the non-ASCII characters got mangled by the XML-RPC implementation used by Movable Type. I had to go in and edit the entry manually using the web interface.

Maybe we should accept that XML-RPC is doomed to obsolescence because of the ASCII-only issue and instead move to SOAP-based APIs for blogging. If so, I have one plea: lets leave the amateurish Blogger and MetaWeblog APIs behind and devise a quality API which enables the development of rich blogging clients. Even when developing a simple blogging client I quickly came across the limitations of the existing APIs.

I'm flying out to Norway tomorrow morning for my annual cross-country skiing vacation. Last year I stayed in Sjusjen, near Lillehammer. This year I'm travelling slightly further north to Espedalen.

I'll be taking my laptop with me even though part of me says that I should leave everything to do with software at home. I might do some recreational programming, just for the fun of it. I've got a couple of ideas I'd like to play with. Maybe something will come of them, maybe not.