|>My current opinion is that client-side state is definitely the way to go.
|>One reason: the user can pause the client, vacation for a week, then
|>continue querying with the state saved in the client (or saved to a
|>client-side file somewhere). If the server keeps state, no matter what
|>form, it must at some point decide when to discard that state, a problem
|>for which there is no good solution. (The session concept has the same
|>problem: will you let a user keep a connection open forever, or will it
|>be shut down after some amount of inactive time?)
There are a number of apps where some sort of state is inevitable. For the
security extensions state must be maintained to prevent replay attacks. It is
not possible to use the time/date for this purpose because not all machines
have GMT and those that do are often baddly configured.
The security extensions also require state to ensure that the first time
a secure area is accessed a warning notice is displayed. This is a legal
requirement to enable prosecution of malicious unauthorized use.
For database operations it seems best to track the state in a manner that
prevents the server having to unnecessarily keep state over periods of years.
For this limiting the detailed state requirements to the persistence of the
connection. This provides a nice balance and allows the clients and servers
to be relatively simple, requiring no long term storage of state.
If we want to look into keeping state outside the connection context then
we should think about Prospero or other protocols. HTML is only meant to
be logicaly equivalent to the universal set of web protocols. We do not have
to optimise for every last case.
-- Phillip M. Hallam-BakerNot Speaking for anyone else.