Taskboy: A Web Services Exhibition. Part 1

The next three posts are about how XML-RPC makes taskboy go, why XML-RPC is better than SOAP and how PHP and perl excel in their own domains. I wrote these as one long article, but, taking pity on my readers, I broke the leviathan into three parts. I expect to be rewarded for my gesture of mercy with crazy-go-nuts xmas stocking stuffers this year.

Web Logs

Although web logs, more popularly called blogs, have recently come to most people's attention during the 2004 US presidential election, the idea of having an easy mechanism to post ideas large and small onto a web site is not new at all. After writing the first dozen or so HTML pages by hand, most of us starting thinking there must be a better way.

Enter the Content Management System

The content management system (or CMS) is a software package that sits on the web server (and perhaps has a special client for your local machine) which faciliates publishing web content and maintaining a consistent look and feel from page to page. The core technology for a consistent look and feel is the use of a templating system. That is, a pattern of code that content can be paired with to generate the final HTML page that visitors to a site view. A natural fit with the use of templates is an underlying database in which to keep the core, user-defined content (and possibly the templates too). So much for web design history up to 1998.

Early CMS tools were written in a variety of languages. Back in the day, Perl was the king of dynamic web applications and was used to build many CMS systems. The trouble with Perl is that it's fidgity in spots to learn and (for some people) it's complexity isn't welcomed as a templating language.

Enter PHP

PHP is a dynamic, perl-like language specifically designed for the web domain. It's both fast and feature-full (and not a little unwieldy at times from problems stemming from it's early lack of namespaces). Knocking out simple, but powerful dynamic web sites with PHP is criminally easy and fast. PHP even has a Windows help file, for those of us workin' on Uncle Billy's farm.

But not everything needed to make a web site go happens in CGI land. There are plenty of system-level things and non-http tasks for which PHP isn't suited (despite some heroic hacks from the PHP community). Wouldn't it be nice to have a way to get the best of both worlds: to use PHP for web front end stuff and perl for backend management?

Enter XML-RPC

XML-RPC is way for programs written in different languages to talk to each other. This concept has the buzzword-compliant name of "middleware" and it's a far from new idea. Programs are, almost by definitions, fiefdoms onto themselves in which data gets trapped. It's hard enough to make computers do what you want to today, let alone try to build software in such a way that it will be useful tomorrow. XML-RPC is the method by which one program's procedure is serialized as XML, passed over a network using HTTP, executed on the receiving machine who then returns the response as XML to be unserialized back into a format mostly easily consumed by the caller. It is a "web service wire protocol" and is the forerunner of the more feature-rich (but strangely less useful) SOAP. This complex dance allows Perl and PHP to use each in appropriate contexts. But what are those contexts? The answer lies with existing CMS.

Thin clients? Fat chance!

The web browser is arguably the most important application to be written in past ten years. In network architecture terms, browsers are thin clients that handle a variety of display issues and a small subset of user input tasks. This is the key to the success of the web. The browser, as envisioned by Tim Berns-Lee, was for reading and changing web pages. By latching onto the read-only aspect, browser makers forestalled what would have been a virtually endless debate about how to implement security for changing web pages. Web page security became the domain of web servers. Which is why CMS systems must be installed on web servers and can, for convenience or to implement specific features, have a client piece on a web author's desktop. Many CMS just used the browser for their client.

And this is exactly the thing that most blogging software does: use the browser to compose entries and manage the content. Blogs, often being simply one page, wouldn't have gotten so popular if each required some kind of special input client on each author's machine. Blogs then are a very specialized form of CMS.

The problem is: I hate composing prose in web browsers. Being a programmer, I've invested a lot of time learning to use a programmer's editor (emacs, in my case). What I want from a blog CMS is to compose, publish and manage my blog entries from emacs editor on my desktop. Now many a blogging CMS have some kind of web service APIs that allow you to hack up glue for your editor of choice to do the same thing that I've done with taskboy. Much of the taskboy system derives from what I did for my use.perl.org journal.

When I decided to move my first blog off use.perl.org, I knew that I wanted to continue using emacs to compose and edit my entries. However, I now had to deal with the front end display logic for the blog. Having written and modified several perl CGI/mod_perl HTML generating programs, I wanted to avoid that solution. Instead, I wanted to learn more about PHP and I'm glad I did.

Next: The dirty details