Friday, March 23, 2007

Libraries, not frameworks

I'm not a web programmer by trade, but I've been known to dabble in it from time to time. Now is one of those times. I've used perl, php, and even C to develop web applications in the past, but my current language of choice is python.

Now, python comes with some excellent low-level libraries for web programming. The cgi and Cookie modules take care of most of the work of parsing HTTP requests and python's WSGI standard adds a slightly-higher level abstraction to the time-honored CGI protocol. Python 2.5's wsgiref module provides utilities to aid developing WSGI-compliant applications and even includes a sample server that makes it trivial to test your web applications.

Unfortunately, the bundled libraries only handle the low-level request handling. For example, localization is important to me, so being able to easily access the Accept-Language HTTP request header is nice, but it would have been even nicer if there had been a library function to parse its contents. Now consider that there are some 28 different request headers defined in HTTP/1.1 and we see that some higher-level libraries would make life easier.

But where are these libraries? They are embedded inside byzantine web frameworks and every framework implements their own. I don't really care to pull in an entire web framework when all I want are the high-level request parsing tools. And code re-use through cut-and-paste just perpetuates the problem. Paste appears to be the closest thing to a library going, but still manages to miss the mark by being a collection of libraries that do various things, not all related.

What I'm looking for is a library: not a framework, a library. I'll make one if I have to -- a small library that does one thing and does it well. Call me crazy, but it doesn't look like I'm the only one who thinks small, sharp tools are the way to do web apps.


jjinux said...

Heh, I was the one who contributed the Accept-Language parsing code to Paste ;)

Kelly Yancey said...

And darn fine code it is. :)

Which reminds me: unfortunately, I didn't record what browser was sending it, but some old perl code I wrote for parsing Accept-Language accepted headers in the non-standard form "en de fr" (e.g. space separated list without q values). The comment in the code simply said "handle old non-standard format", but a quick google yielded no hint what browsers might have been sending that.

Ever since I ported that code to python, I've been intending to re-test with all of the old devices I had to test with back when I wrote that code in hopes of discovering the culprit (and record it in the code comments this time!). I have a sneaking suspicion it was an old Zaurus.

Anonymous said...

video poker