Web Services, Weblogs and the Future.

   Print.Print
Email.Email weblog link
Blog this.Blog this
Timothy Appnel

Timothy Appnel
May. 23, 2003 01:27 PM
Permalink

Atom feed for this author. RSS 1.0 feed for this author. RSS 2.0 feed for this author.

In recent weeks a significant amount of discussion has been ongoing as to the future of Weblog APIs. At issue is that there are two similar, but different Web service APIs in use -- the Blogger and MetaWeblog APIs. Within each of those APIs are various interoperability and implementation issues and even some extensions. The community clearly wants one tool-agnostic API that all can utilize and integrate tools with, but there is differing views as to how this will and should happen.

The discussion began with a review of the existing Weblog APIs on Diego Doval's site that lead to a long thread of comments and follow-up posts. Adriaan Tijsseling creator of the Kung-Log Weblog authoring client offered his thoughts on the matter having worked extensively with numerous implementations available. Most notable in the recent posts is the one by Blogger's Evan Williams where he explains how their API came to be and why Blogger has not supported the MetaWeblog API. He agrees with the call for a universal blogging API and adds that no one vendor control it. He concludes "I perhaps now understand the need for standards bodies more than I ever have before even though the term gives me willies."

I think that such an universal interface would be a great for the weblogging community and beyond. There absolutely should be one interface that we all can utilize and rely on. (It shouldn't necessarily be limited to just weblogging publishing though.) And yes, standards bodies give me the willies also.

This all being said, I'm left with some nagging questions and omissions in the design and implementation discussion that could effect the utility and effectiveness of such an interface -- international character support, robust extensibility and cohesion with RSS.

The most important amongst these issues is XML-RPC's lack of international character support. Adriaan Tijsseling noted to me that Apple's WebServicesCore and MovableType's API support UTF8 in XML-RPC, but according to the XML-RPC specification strings are limited to ASCII thereby undermining international character support. There have been numerous threads in the past on this issue such as this one made by Charles Cook.

To a lesser extent, but still significant, is robust extensibility. As weblogging expands and evolves, feature sets will become more diverse and feature sets in tools will begin to vary and hybrids emerge. What effect will this have on interoperability? What XML-RPC lacks is a straight-forward and reliable way for it to be extended when warranted -- whether that's between two weblogs or two million. In comparison to straight XML, a XML-RPC struct is not straight-forward -- its quite verbose. Structs in XML-RPC don't have the benefit of utilizing namespaces and thereby cannot directly leverage previous work such as Dublin Core. Back in January, Sam Ruby published "Evolution of the Weblog APIs" that amongst many things, highlights this issue by comparing the implementation of services with XML-RPC and other formats.

The simple answer to both these issues would seem to be that the XML-RPC specification should be modified to address these issues, however XML-RPC has been declared frozen and not subject to change.

So I wonder aloud, is a broad API based on XML-RPC the way to go forward? This is a difficult question to definitively answer given the existing landscape, but given the circumstances one worth of consideration.

Furthermore, RSS and Weblog APIs are working with the same data -- why are two very different formats needed? As I have asserted in the past, RSS is a Web service we already have. RSS is even more widely deployed then either of these Weblog APIs. It can handle all international character sets and with the introduction of modules in 1.0 and copied in 2.0 you have all the extensibility built-in you need. RSS over HTTP (perhaps even wrapped in a simple SOAP envelope) may be a better long-term solution in terms of extensibility, simplicity, and international support. Merging syndication and APIs in this space seems a plausible and worthy consideration. This notion puts even more emphasis on the need to clean-up and better define RSS.

These are a difficult and contentious issues without easy answers. Nevertheless they are better addressed now rather then later in serving the long-term good of the community.

Timothy Appnel has 13 years of corporate IT and Internet systems development experience and is the Principal of Appnel Internet Solutions, a technology consultancy specializing in Movable Type and TypePad systems.