|One of the mildly irritating things about XML-RPC is that it doesn't support named parameters directly. This makes it slightly more awkward to have standard function calls with optional parameters. But there's a simple fix for this which is to encase all the parameters into a struct in which case all the data is held in name-value pairs. I think this is actually a strength of XML-RPC because it provides two ways of encoding parameters at a very small cost in extra complexity for one of them.
In the last few days, we've seen another outburst of creativity among the various people thinking about a universal weblog API. The push to build a replacement and extension to the original Blogger API had already thrown up 3 or 4 attempts. Now Userland has thrown another into the ring and done so with an implementation as well as a spec. This has also caught the attention of Ev and so might easily find it's way into Blogger and Blogger Pro. At which point the sheer weight of deployment will make it a de facto standard that everyone else has to support as well. Interestingly, most of the new attempts including the one from Radio holds most (but not all) of the parameters in a struct. This is a good thing but if you're going to use a struct for some of them, why not use it for all?
Which is all well and good except that the original API had a number of highly Blogger Specific features and was brittle as it used plain parameters. And it's pretty easy to see that every attempt so far has the same problem that some aspect is unique to the specific system that the author is really trying to support. It doesn't feel like any of the authors have completely taken on board the idea that this API should be universal across as many different blog system architectures as possible.
Then there's the social problem of how standards like this are developed. Very occasionally a standard is developed and succeeds as a group effort. But in almost all other cases, a single (more or less benevolent) dictator in the form of an individual or organization drives the standard forward and makes it happen. So we have Ev and Blogger creating the first. And Dave and Userland creating the second. The rest of us can scream and shout and moan that they got it wrong and we may think that they have a duty to listen and take our comments on board. But in reality, there is no duty. The standard will succeed or fail on a combination of it's merits and the extent of the deployment. We may not like this, but it's the way it is.
So why am I saying all this? Well I wrote a Blogger API for Drupal and Drupal specific extensions and I use the Drupal version every day to communicate between a Delphi desktop blog editor and this blog in PHP. But frankly, I put no effort into promoting it beyond the Drupal community and in retrospect I got the API wrong. It works for me and gets my job done, but like everyone else I made it specific to the system I wanted to use.
I suspect the window has now closed for a while and the chances of producing an elegant and global standard are pretty slim. No matter how flawed the Blogger and Userland versions are, they've got the critical mass of deployment. But that doesn't stop me thinking about it and trying to come up with a solution in my head. I'm just not sure I've got the energy or time to justify and argue the case on the weblog-devel mailing list.
Enough ranting, here's some pointers.
Put everything in a struct and use named parameters. If a server gets a param it doesn't know, ignore it.
Have a bare minimum of primary function calls. I reckon you only need 4
setBlog() If you supply a postid, update, if you don't insert.
getBlog() Return a complete post
delBlog() delete a post identified with a postid
listBlogs() return a list of postids.
Use type string everywhere. You can't hope to get any commonality on the exact format of things like postid.
A post only has three elements. These are almost common across all systems. But if a system doesn't support one just ignore it. And if one is not supplied then auto-generate it.
Postid Every system has a unique id for identifying a post
Title If there's no title and you need one just come up with a heuristic to use the first n words of the body
Body self evident.
Every system uses a userid/password to identify the user so we better put those in.
Quite a lot of systems allow multiple blogs. by no means all, but enough to make it worthwhile including something for this. So we better have BlogId as well.
So that leaves us with:-
setBlog(struct(userid, password, blogid, postid, title, body)) returns postid; //postid=0 for failure
getBlog(struct(userid, password, blogid, postid)) returns struct(postid, title, body);
delBlog(struct(userid, password, blogid, postid)) returns boolean;
listBlogs(struct(userid, password, blogid, count, [start])) returns array(postids);
//return the last count postids, unless start is specified in which case return count postids starting at postid=start.
So there you have it. Simple, elegant, minimal. Everything else is an extension for a specific system. Guess I better go and write some code now.
[ << RCS ] [ spamradio >> ]
[ 19-Mar-02 8:42am ]