Re: making progress on State-Info

>The advantage is that you can maintain several state-registers particular
>to parts of (or the whole) server without returning a full session history
>with each request; the token-database is client-side.  The disadvantage is
>that you blow away Dave's provision for an unspecified header-content.  A
>side effect would be the need to return more than one state-info token in
>the same request.

Sure. This will work, but, as I said, this is only one way. It will also
limit the implementation to using hierarchical organizations of state
information. That sort of organization is not optimal for flat look up.
Either the HTTP protocol provide complete support for various mechanisms for
implementing state or it punts it to outside programs, essentially acting as
a communication mechanism for state information between clients and servers.
Obviously, the first is not what we want to do. In that case, we are left to
do the second. 

Much like Roy argues for opaque cache identifiers (and individual servers
implementing their own mechanisms for comparisons), I am arguing for opaque
session information. Let server writers or CGI bin script writers implement
different quality of service features that they want, for the type of
session management they want to do.

Sankar Virdhagriswaran                         Phone: (508) 287 4511
Crystaliz Inc.                                 Fax:   (508) 287 4512

Received on Saturday, 9 December 1995 17:15:12 UTC