From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <2cc4c8d87723314234f4e746ca9b0fc0@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon, 27 Apr 2009 08:03:15 -0400
To: 9fans@9fans.net
In-Reply-To: <1240783702.25846.60.camel@goose.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] web server
Topicbox-Message-UUID: f337359a-ead4-11e9-9d60-3106f5b1d025

> On Sun, 2009-04-19 at 00:13 +0200, Uriel wrote:
> > My criticism was directed at how they are actually used in pretty much
> > every web 'framework' under the sun: with some hideously messy ORM
> > layer, they plug round Objects down the square db tables, and all of
> > it to write applications which really are representing files (accessed
> > over HTTP).
>
> I'd say that the biggest reason for DB overuse by Web folks is the
> fact that this is how they get persistence for their data while
> still being able to build distributed applications.
>
> In general, there are only two ways of having persistent data:
>    * DBs
>    * FSs
> (well, ok, there's third these days)
>
> FSs (under most OSes) have been way to clunky in the presence
> of any kind of distribution. Hence the DBs.

i agree that this is the general line of thinking, but i think option #3
is missing.  there's lots of ephemerial data that doesn't make sense
to keep in a database even if you have one.  if you do cc processing, some of it may
be unwise to let the cgi see or illegal to store in a database (example:
the verification code from the back of a credit card).  so i always thought
it made sense to have a session server to deal with these problems.
we kept the connection information fit to keep in the filesystem.  that
was pretty easy.

- erik