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".
[email protected] (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 <[email protected]>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------