W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1995

Re: State and tracking need to be separated (Re: session-id redux)

From: Terje Norderhaug <Norderhaug.CHI@xerox.com>
Date: Fri, 28 Jul 1995 12:48:01 -0800
Message-Id: <ac3eefa30202100445be@[130.191.70.82]>
To: burchard@geom.umn.edu, www-talk@w3.org
At 1:45 AM 7/28/95, Paul Burchard wrote:
>Once we can focus on the issue of state by itself, I believe it
>will also become clearer that HTTP headers (not only Session-ID: but
>also Authenticate:) are the wrong places to put it.  Any proposal
>that does not support client/server balancing, and instead imposes
>all the burden of state maintenance on the server, is unacceptable.
>Hidden form fields can already do better.
>
>My inclination would be to use Web links to attach state, and
>remove the issue from the HTTP protocol level altogether.  This will
>keep HTTP itself "stateless" (giving more freedom to future
>evolution of HTTP).

Although I think that state-changes attached to links should be combined
with other approaches, it might have its advantages to keep state
information as part of an HTML document. In the WWW tradition it visualizes
what is going on even for service providers that are not overly
technologically savvy, improving their learning and application of the
functionality. Also, state information as part of HTML makes it easy to
create links from any web document to a specific state of a service, in a
similar (but more flexible) way as it today is possible to make a link to a
search service that contains a search term, and thus get a dynamically
created page as the result of the query, e.g.:
<URL:http://webcrawler.com/cgi-bin/WebQuery?search+engine>

We have previously touched into the problem of backtracking when the state
changes are in the links: "Shopping-baskets" loose their content as the
user go back in their history. However, this might be solved by attaching
state change information to a link contained in the head of the document
(e.g. base), signifying that a document based on this state change should
be reloaded when the user moves backwards. Such state changes might confuse
the reader if it implies changes in the document, as they might expect
documents in their history to not change, so it might have its
disadvantages to give the service provider this power (although I am in
favor of it).

>I'm working on a more precise proposal for state links,
>but feel free to jump in.

Feel free to post a draft.

-- Terje <Norderhaug.CHI@Xerox.com>
   <URL:http://www.ifi.uio.no/~terjen/>
Received on Friday, 28 July 1995 15:46:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT