I'm working on an application that would take advantage of this sort of
capability, but I don't think it requires abandonment of statelessness. My
experience so far tells me that when the user wants to perform multiple
queries and transfers, it's because they are somehow related to one
another. I'm attacking that problem by passing parameters, which are kept
by the *browser* and re-sent. I see the need for improvement of the
browsers' ability to keep track of queries and such, based on interaction,
rather than a need to change the servers' capabilities in that area.
There are several examples of outline interfaces (one of the capabilities
that I'm working on) that allow a variety levels of expansion in
subheadings. At first glance, you'd think that that would require the
server to record the state of the outline, but the people who've done it
actually just create an document that contains a list of parameters
describing the outline's state, then pass those parameters back to the
server on each subsequent query. I can dig up URLs for examples if they're
wanted.
>I'm currently using another port to perform the database queries using an
>intermediate script (ie, the client asks for something, a gateway then makes
>a complicated set of queries on another port, and returns the results to the
>client). This will likely turn out pretty well, but I'm looking down the
>road and thinking it would be cleaner to move some of the stuff directly
>into HTTP. For instance, the client requests some information, and gets too
>much information returned. It then wants to apply a URC (or SOAP) to the
>previous query to narrow the search.
There's no reason that the subsequent query can't pass back to the server a
set of parameters that describes the previous search results, to which new
narrowing or widening parameters can be added.
>If the protocol is completely stateless (as any MIME-oriented MGET proposal
>is), it will have to resend the entire query, forcing the server to do all
>the processing again. Only in a stateful protocol can this be implemented
>cleanly and efficiently.
I guess another way I can say this is that you don't have to send the whole
query back, merely a description of it or a description of the results.
But as I think about this, I can imagine that eventually the results might
become quite complex, using up a lot of bandwidth to pass. But again, the
solution isn't necessarily to store a state. The server could simply cache
search results so that if it sees a duplicate search request, it already
has the results on hand. It becomes a performance issue rather than a
statefulness issue... and I'd much rather predict that performance will
improve than to bet that we can guess what kind of statefulness should be
built into the servers.
Finally, just to throw a different vocabulary on this, I think about it as
"transaction" v. "session" models. In a transaction model, there's user
interaction at every step; in a session model, the browser carries out a
series of recorded or defined steps. This is coming from my experience
with CompuServe, where the two models are well-defined and widely used.
CompuServe is almost stateless. And I hasten to add that *the* biggest FAQ
in a forum is "why did my message disappear," which is a result of the fact
that the system records the users' last message read and by default doesn't
show any messages before that number during the users' next session --
including any messages that he or she might have posted. See what having a
stateful server does? ;-)
Nick
Multimedia Computing Corp. (strategic consulting)
Campbell, California
----------------------------------------------------------
"We are surrounded by insurmountable opportunity." -- Pogo