Blog Trickery Using XML-RPC

I was recently asked by a client to explore a proof of concept to create a servlet within the CQ system that could receive requests via XML-RPC from a mobile or desktop based WordPress blogging application and basically trick it into thinking it was communicating with a WordPress blog. The idea was to let the authors of their blog pages have the flexibility to use pre-existing blogging applications without having to limit the pages themselves to rely on pre-fabricated blogging solutions such as Blogger, WordPress, or Movable Type.

Basically XML-RPC is an xml standard for sending and receiving “Remote Procedure Calls”, so at first this seemed like a pretty cool solution. However, as I continued to investigate, I discovered several obstacles with this approach.

First off, there are three leaders in the blogging world, all of whom have their own APIs (Blogger, WordPress, and Movable Type) as well as a Microsoft standard called “metaWeblog”. All four of these APIs have different standards based around XML-RPC, which didn’t initially seem like a concern since the client only wanted to support WordPress applications. As I explored further, creating a dummy servlet that began to catch all POST requests and perform logic based on the node in the content of the request, I realized that even if you specify that you should be communicating with a WordPress blog only (from the configuration of your blogging application), your server will still end up fielding requests using all four APIs, effectively quadrupling the effort of coding the servlet.

Add to this that even parallel methods will often have a slightly different request/response data-structure, and you wind up with kind of a pickle. The end result would have been a servlet that catches all POST requests, parses the request and processes the data one of 50 different ways based on the method name, and sends back a properly formatted response to the client application…not impossible, but not all that graceful either, and that is before you deal with saving and editing posts in an actual repository structure.

Ultimately the client decided it was more effort than it was worth (at least initially), but the entire experience was quite interesting, so I figured I would share. If they end up wanting to revisit this idea at a later date (and if I end up being the developer they choose to implement it) I’ll post part II.

Leave a Reply

You must be logged in to post a comment.