To be clear, what you're proposing is an additional mechanism for
storing state on the *client* side. As far as I can see, we already
have good mechanisms for this. Even though the most flexible ones
are HTML-specific, any format which supports URL-based links can play
the game. And as long as the client caches (or the user saves)
documents containing such links, the client-side state will even
automatically persist across client sessions.
> C: GET /Flux HTTP/1.0
> State: 1-29
> S: Content-type: text/html
> State: 1-34
> <file with just 5 elements>
How is your scheme essentially different from either of the following
two scenarios, the first of which will work with any URL-based
hyperformat? The only difference I see is that your scheme relies
on client caching of meta-info, which may be problematic (see below);
while the following schemes rely either on either client caching of
history, or on manual saving of documents (available in any browser).
C: GET /Flux/1-29 HTTP/1.0
S: Content-type: text/html \n\n
Item 30 ... Item 31 ... Item 32 ... Item 33 ... Item 34 ...
Save this document to read <A HREF="/Flux/1-34">new articles</A>
C: POST /cgi-bin/Flux HTTP/1.0
Content-type: application/x-www-url-encoded \n\n
state=1-29
S: Content-type: text/html \n\n
Item 30 ... Item 31 ... Item 32 ... Item 33 ... Item 34 ...
<FORM...><INPUT TYPE="submit" VALUE="Read new articles">
<INPUT NAME="state" TYPE="hidden" VALUE="1-34"></FORM>
Your more elaborate examples can be emulated in similar fashion.
> To sum up, this requires [...] minimal changes to the
> client (clients keep around a history of visits to URL's
> anyways, this is simply associating a value with that key).
I'm not sure that it's a good idea to associate State meta-info with
URLs, as opposed to individual documents and links. What if I wanted
to go back and switch to reading latest batch of articles with
different output filters enabled (or whatever)? It would seem
natural to turn back to the page where I clicked to get this batch,
and then select a different option. That wouldn't have the expected
result if the State meta-info is associated to the URL rather than
the link.
In any case, I feel that all of this unrelated to the need for
"stateful connections" in HTTP, because the purpose of stateful
connections is to support *server* side state. It is the lack of
support for both server-side state and client-side computation that
(in my opinion) is holding the Web back from becoming the world's
coolest distributed object environment.
To be sure, these are the better features to omit on the first pass.
But I think that's where W3C needs to be putting some serious effort.
It looks like proprietary solutions could soon dominate if W3C
doesn't take the initiative. I'd be eager to work with them on such
a project.
--------------------------------------------------------------------
Paul Burchard <[email protected]>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------