Now blogging at diego's weblog. See you over there!

blogging APIs update

It's been a little over a month since I wrote up my review of blogging APIs, which caused a bit of a stir in blogging circles (not necessarily because of its contents, but because it revived a subject that has been contentious for a while). I wrote a couple of followups (here, here, here and here) which contain links to comments and information from others in the community.

I decided to wait for a bit before commenting further, and now it's time :).

A couple of weeks ago Timothy posted some good comments on his O'Reilly weblog and that resulted in further discussion with Dave.

The discussion expanded to include some of the limitations of the XML-RPC spec, in particular those that deal with internationalization. Dave's contention is that because the API is so widely deployed it can't be changed, and people have found ways of doing i18n on their own anyway. In my opinion, however, it would be extremely useful to formalize those workarounds for the simple reason that if, anyone that wants to use i18n has to find a workaround on their own it is extremely likely that they will end up with similar, but slightly incompatible versions of the same thing (pretty much the state of blogging APIs at the moment). The same applies to any limitation, not just i18n, but i18n is a clear problem that will grow as people from the other parts of the world start using these tools (and eventually they will outnumber english-speaking (or should I say ASCII-speaking?) users).

Point in fact: At the moment the weblog posting feature of clevercactus implements Blogger and Metaweblog, along with a couple of MovableType API extensions for dealing with categories. For both Radio and MT I can use the same method call from MetaWeblog to create posts. But, I'm not dealing properly with i18n, which MT supports. So now I will be forced to completely splinter the implementations and the slight advantage that I could see in implementing MetaWeblog for both MT and Radio vanishes, so cactus will be better off using the tool's specific API in each case. Which brings us back to the need of having a single API that is extensible and, preferably, transport dependent (ie., the API has been defined without relying on XML-RPC, SOAP or REST, or anything else, and there are several "transport-specifications" for it). After all, we are trying to define the what that is transfered, not the how.

The same applies to RSS, on which there has been some movement. Dave proposed that work should start on a common profile, Sam agreed, and good discsussion followed on his post, and then it went on from there. (Timothy has a good summary of the RSS core profile here). It seems that it is easier to get to agreement on RSS than on the APIs, which gets back to my point: RSS is a data format specification, while the APIs mix both data and transport. If data and transport could be separated in the API spec I think it would be easier to move it forward.

Categories: technology
Posted by diego on June 5, 2003 at 3:09 PM

Copyright © Diego Doval 2002-2011.