This past month gave me a newfound respect for specification writers. I remember when James Davidson marshaled the early Servlet API and the lively discussions that ensued on the mailing lists, basically coordinating the entire operation (no JCP in those days, eh?!). The point is, at least there were discussions and, more important, a formalized document was produced at the end of the process. This past month I found myself dabbling in a number of technologies that sat outside the comfort of Javaland.

For a project I'm involved with (Blog-City), I was tasked with building the XML-RPC interface for the widely used Blogger API. This XML-RPC API has a handful of methods for updating your blog site remotely, enabling you to view recent posts, upload and edit posts, and all the normal things you would expect. All seems pretty simple so far, but the problem is that the documentation for this API is thin on the ground, and the one HTML page that does exist is over a year old. A trawl through the mailing list archives shows a lot of frustrated would-be users of their XML-RPC left out in the cold.

I did manage to figure it out eventually by looking up the source code from one of the SourceForge client projects to see what results they were expecting from the server. My aim was not to build a client, but the server side of the fence, so I wanted to make sure I caught all the different calls that could be sent to me. Although I have to say the irony wasn't lost on me that one of the world's leading blogging sites couldn't keep a page on their own API up-to-date!

Having now drafted the overall protocol flow, the job of actually providing the server functionality was next on my list. A quick look in Google and I discover the wonderment that is known as Apache's XML-RPC library. This was simply a joy to use. Take a single JAR file, easy-to-follow instructions, and within three lines of code, I had a complete server running that accepted and processed XML-RPC requests. No special classes or interfaces to implement. No complicated descriptor files to maintain. It just worked, straight out of the box so to speak.

The whole process was a resounding success. But as the day ended, I reflected on the whole situation and how it highlighted the importance of standards bodies and specifications.

In many respects the Java world is lucky; by and large, we seem to do it right. We keep it open and try to involve as many people as possible. After my recent experience, I now think of Blogger as the Microsoft of the blogging world. There was no sign of any openness or even an effort to involve the community in the design and maintenance of their API. It was their way or the highway. Legions of client-side tools had come to accept the fact that they would need to keep an eye on the main server and continually update their own software for changes. Because one day, it just might not work.

As we know, such blind ignorance of the world around doesn't work. There are alternatives to the Blogger API, much better APIs in terms of documentation and proper version controls. These APIs, I am sure, will persist far longer than the Blogger API, simply due to the fact that there is a published specification.

For this reason, I am very happy to be in the Java camp as opposed to the C# (a.k.a. .NET) camp. At the end of the day, I feel secure knowing that when I call a particular method, it's going to be there the next time I make the call, and the next time, and so on. One day it isn't going to stop working because someone decided to tweak a method signature.

We take specifications for granted at times and, on behalf of the community, for all those who take the time to formalize the standards we rely on, I thank you. Keep up the good work and, more important, keep listening!