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

It looks like I need to clarify what I meant by using links for state.

First, by "link", I don't just mean the <A> element in HTML.  The  
"link" is one element of a conceptual model of the Web as it is  
presented to users and handled by user agents.  There are many  
concrete ways to request the creation of links, such as the <A>  
element in HTML, the Link: header in HTTP, the WWWAnchor{} node in  
VRML, and so on.  The statefulness I am talking about is happening  
in this more abstract "agent" layer, above the specific formats and  
protocols.

Second, the current agent-level model of the Web is rather vague  
about state.  This vagueness is already causing problems -- witness  
the controversy over the Expires: header, which may or may not be  
introducing statefulness for Web objects (does expiration destroy  
backtracking history?).  What I'm proposing is that the Web model of  
links explicitly support some kind of statefulness, to permit  
_destructive_ updates of the agent's associations between objects  
(links with "assignment semantics").

The point is, once the agent-level Web model has some kind of  
support for stateful objects and/or stateful links, two  
communicating Web agents can use this to cooperatively (and  
balancedly) maintain state information, even if in the lower layers,  
the communication protocols and object formats involved are  
"stateless".


Norderhaug.CHI@Xerox.com (Terje Norderhaug)
> 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.

Well, updating by reloading on backtrack would defeat the whole  
purpose of client-side state caching -- it would then be simpler to  
just use session-ids as keys into a server-side database.  What I'm  
suggesting instead is _destructive_ update of a link from the old  
documents, in order to point them all at the new state object.   
Either client or server could request the other to make such a  
destructive update.

Although script-generated documents could threoretically contain  
the new state links internally, I'm mainly thinking of links  
_external_ to a document, specified with the help of HTTP Link:  
headers.  That's because you typically want to also communicate the  
target of the link (the new state object) at the same time.

--------------------------------------------------------------------
Paul Burchard	<burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

Received on Saturday, 29 July 1995 09:19:24 UTC