Patrick (patrickwonders) wrote,
Patrick
patrickwonders

  • Mood:

Say it with me folks, "Mo-du-lar"

As mentioned in a previous post, I really want to revamp the nklein website. With my recent obsession with Lisp, I wanted to do some of it in Lisp.

I'd like to score each of my projects on some number of scales... sort of a fuzzy tags thing. Then, I'd like to use Vecto to generate a navigation icon based on the scores on the different dimensions. This would be cached, but generated when dirty.

I'd like to add trackback pings (or something similar). I'd also like to use the LiveJournal XML-RPC interface to pull journal entries with particular tags onto a page at nklein.

Here's the thing though. VPS hosting costs an arm and a leg. On the other hand, I can get a large amount of disk space and a shell account with a compiler on a Linux machine for $5.95 per month. But, they don't support mod_lisp and it would be really awkward for me to run my own web server from my account on a different port and such.

So, now we get to the subject line of this post. There are a variety of Lisp frameworks out there for doing dynamic web applications with Lisp. Some of them will work through mod_lisp. All of them will run as a stand-alone web server. I want to do the same sort of call dispatching, but through FastCGI or just really fast CGI.

With a great deal of mental effort, I may be able to adapt Hunchentoot to dispatch from FastCGI. But, that leads me to the whole issue of FastCGI. Right now, even when running behind mod_lisp, Hunchentoot still expects to basically be a stand-alone webserver.

There's also FastCGI code out there for Lisp. The FastCGI code has mingled together stuff to unescape URLs and form data, stuff to parse time stamps, code to actually deal with the FastCGI, and code that can only possibly work with CMUCL. I tried several approaches to pulling it apart a bit so that I could try to get it running with SBCL or something else. I finally just scrapped it in favor rolling my own. That's an adventure unto itself because whilst the FastCGI spec is very clear on where you'll find the values in messages, they're not at all clear on which directions messages will go (to or from the web server), and they're not really interested in telling you what the value of any of their constants are. You have to read other implementations to suss those things out.

So, I'm writing a package to do FastCGI. I'm writing a package to decode webby-escaped things. And, then, I'm going to try to get Hackentoot welded onto this. Of course, I may be able to leverage the webby-escaped stuff that must be in Hackentoot if I can weld to the FastCGI. Or, I'm going to be writing my own again.

There's also some XML-RPC stuff out there for Lisp. Being a client seems pretty do-able. Being a server (to accept Trackback pings and such) is a whole other ball of wax. Here again, it's married to the idea that it's going to be a stand-alone web server. If you want to make an XML-RPC server, then obviously, you want it to run in its own web server. You wouldn't want to leverage the web server you already have running. That would be silly.

Further, it appears as though the power or network has gone out in my home. So, I can't get to the stuff that I started working on before. So, I've gone through the other Lisp code that I've written so far. I got all of my installed packages working with both SBCL and CCL (OpenMCL) now. I've got all of the code that I've written working with CCL now, too... except for the SDL-based code that I started on last week because CCL is 64-bit only and right now I only have 32-bit SDL frameworks installed. *shrug* So, it's frustrating that SBCL doesn't support threading on non-x86 hardware and that CCL doesn't support 32-bit x86 hardware. So, I'm having trouble writing all of the code that I want on my home Linux box (32-bit x86), my home PowerBook (ppc), and my work Desktop machine (64-bit x86). Wheee.

Tags: lisp
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

  • 6 comments