Unfolded Mind

Yet another monad tutorial, but this time with Major Tom!

Best dog, ever!

She jumped off the bed, injured her spine, and spent 3 days whacked out on muscle relaxers. This morning, around three, she just gave up.

Okay, this is an idea that’s been developing in my mind ever since I realized how closely the secrets of the internals to Quicken® were held. Build a personal finance application that uses RDF as the backend store. every time I’ve tried to do something in an SQL database, or as a spreadsheet, I run into the problem of imperfect data representation: if you don’t get your table models pretty close to what you’ll need when everything is finished, you don’t really have much that’s useful. RDF gives you a graph representation that can mimic tables that are arbitrarily wide. RDF remebers facts that are important, while allowing you to change your mind about  what’s essential. I’ll post more once I know more.

Well, been consulting for a small health insurance non-profit since mid-October. The possibility has been held out that I might get hired in January.
We’ll see!

Laid off 3 weeks ago.

You know you’ve watched too much “Invader Zim”, when the phrase “slaughtering rat people” gets stuck in your head like a disco song from the 70s

I’m on Technorati now.
Technorati Profile

My bright idea, the one where I do a HEAD request, and then decide how to handle it?

Not gonna work. Things just get too confusing in the case of a POST.

I’ll have to do some major re-thinking, and revert some things back the way they were before.

Nobody said this would be easy, now, did they?

When the Netscape web server first came out, about 58 web-years ago, they touted the ability to write server-side scripts in a new language called “javascript”. Well, guess what? now there’s
v8cgi from from google, which lets you do the same thing.

Big deal? Maybe it is. Javascript has come a long long way from the days when it was just used for rollover images. Imaging applying the power of jQuery to your server-side development. Is this an easy way to reach the nirvana of functional web programming I’ve been seeking?

Okay, the latest: I’ve fixed the incomplete headers problem, and found a solution to proxying non-XML resources: not to do it at all!

Here’s the way klortho now behaves. It parses the request URL, does a HEAD request on it with the original HTTP headers from the user’s browser, and then takes 1 of 3 actions. If the returned status code is anything other than “200 OK”, it returns the headers it receives. If it gets a “200 OK”, but the “Content-Type” is anything other than “application/xml” or “text/xml”, it sends a “301 Moved Permanently” status, with a “Location” header pointing the user’s browser to the URL parsed from the “PATH_INFO”. This tells the user’s browser that klortho is not interested in brokering this request, and to kindly just get the resource directly from now on, thankyouverymuch. Only if it has a “200 OK”, and the right XML content type does it go ahead and retrieve the body of the response, and process and return it.

Still unfinished:

1. POST requests. This is a biggie. If the checks succeed, klortho will have to pass in the POSTed data it receives. libCurl has a good tutorial on this. It’s should be straightforward.
2. Some response headers may need to be adjusted on the way out, the ones that relate to proxying.
3. Authentication will need to be transparently passed through

Keep checking back, I’ll keep you updated. If you feel like contributing, let me know.

The Links:

• The “Show” script, without klortho
• The “Show” script, with klortho
• The “Rate” script, without klortho
• The “Rate” script, with klortho
• klortho source