Statelessness

• Mail folder: WWW Talk Apr 94-present
• Next message: Christopher J. McRae: "Support for User-Agent?"
• Previous message: Nick Arnett/Multimedia Computing Corp.: "Statelessness"
• Maybe in reply to: Nick Arnett/Multimedia Computing Corp.: "Statelessness"
• Reply: burchard@geom.umn.edu: "Re: Statelessness"

Errors-To: listmaster@www0.cern.ch
Date: Mon, 16 May 1994 21:21:31 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <199405161916.MAA08301@osiris.ac.hmc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: Jared_Rhine@hmc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Jared_Rhine@hmc.edu
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Statelessness
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

Nick> There are several examples of outline interfaces (one of the
Nick> capabilities that I'm working on) that allow a variety levels of
Nick> expansion in subheadings.  At first glance, you'd think that that
Nick> would require the server to record the state of the outline, but the
Nick> people who've done it actually just create an document that contains a
Nick> list of parameters describing the outline's state, then pass those
Nick> parameters back to the server on each subsequent query. [...]  There's
Nick> no reason that the subsequent query can't pass back to the server a
Nick> set of parameters that describes the previous search results, to which
Nick> new narrowing or widening parameters can be added.

What's the difference between "recording state" and "describing the state"?
In general, the examples and discussion in your message seem exactly like
recording state to me.

I don't really think of HTTP and gopher as "stateless" protocols, although I
use that terminology.  They're not "stateless"; rather, you are simply
tracking the state on the client side instead of on the server side.  What I
am claiming is that allowing state to be recorded _only_ on the client, thus
requiring two transfers on the state information for every change in state,
can lead to very inefficient applications.  HTTP should provide a mechanism
to allow the developer to decide where to record the state.

Nick> I guess another way I can say this is that you don't have to send the
Nick> whole query back, merely a description of it or a description of the
Nick> results.

But in many cases, a description of the results is as large as the search
results.  And in Interpedia queries, there may be large parts of the data
structure that were constructed, but not returned in the final answer.  I'm
saying that I might want to retroactively tweak the search parameters so
that those items become an answer to the search.  Thus, merely describing
the results is not sufficient.

Nick> But as I think about this, I can imagine that eventually the results
Nick> might become quite complex, using up a lot of bandwidth to pass.  But
Nick> again, the solution isn't necessarily to store a state.  The server
Nick> could simply cache search results so that if it sees a duplicate
Nick> search request, it already has the results on hand.

Then the server is storing the state.  The problem is that recording the
search results can suck up an enormous amount of space very fast.  And I'm
talking about performing searches, but with little tweaks to the parameters.
This means I need to keep around the entire data structure that I
constructed to arrive at the previous search.  Caching of results is not
sufficient for this application.  As far as I can tell, the only clean way
to perform these kinds of operations are with stateful protocols.

Hmmm, I guess I could maintain the inherently stateless nature of HTTP and
instead maintain some transaction identifiers.  That is to say, the HTTP
server keeps all the data structures for all the searches around, and knows
which one to work with based on the transaction id sent by the client.  This
might work, although the communication model will have to be changed, since
you'll lose the file descriptor when you drop the connection.  Maybe some
other form of IPC would be appropriate.  Does anyone have any experience
with using transaction IDs in an inherently stateless protocol?

-- 
Jared_Rhine@hmc.edu | Harvey Mudd College | http://www.hmc.edu/~jared/

"Tiger gotta hunt.  Bird gotta fly.
 Man gotta sit and wonder why, why, why.
 Tiger gotta sleep.  Bird gotta land.
 Man gotta tell himself he understand." -- Kurt Vonnegut Jr.