Re: statelessness

redback!jimmc@eskimo.com (Jim McBeath)
Errors-To: listmaster@www0.cern.ch
Date: Sun, 29 May 1994 05:33:09 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405271958.AA12683@redback.>
Errors-To: listmaster@www0.cern.ch
Reply-To: redback!jimmc@eskimo.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: redback!jimmc@eskimo.com (Jim McBeath)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: statelessness
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Earlier this month there was a brief discussion on state in HTTP servers,
which I just now got around to reading.  For anyone interested, I've
got an experimental server which maintains state by controlling subprocesses,
assigning them to clients and keeping track of it all.  This allows arbitrary
state to be kept in the server, since you can write any program you want
to keep the state.  Plus it doesn't clutter up the http daemon with any
kind of data description language, which might otherwise be required in
order to allow keeping arbitrary state usefully.

The server is accesable at <http://alumni.caltech.edu:8000/>, source for
the program is also available there.  A fair number of people have poked
around there, but so far no one has made any comments.  I view it as
an interesting exercise, but probably not useful for anything real.

My current opinion is that client-side state is definitely the way to go.
One reason: the user can pause the client, vacation for a week, then
continue querying with the state saved in the client (or saved to a
client-side file somewhere).  If the server keeps state, no matter what
form, it must at some point decide when to discard that state, a problem
for which there is no good solution. (The session concept has the same
problem: will you let a user keep a connection open forever, or will it
be shut down after some amount of inactive time?)

Jim McBeath
jimmc@eskimo.com
http://eskinews.eskimo.com/~jimmc/