Re: making progress on State-Info

At 4:10 PM 12/9/95, Koen Holtman wrote:
>The discussion was on whether
>the state-info mechanism proposed by Dave Kristol should be extended
>with a `path=' attribute as in Netscape cookies.  Someone suggested
>that this might allow for more session state to be kept without
>resorting to server side databases, if I remember correctly.

Yes, I proposed the addition of "path" to try to address Lou's concerns
about the usability of state-info.

>I remarked that I failed to see how that `path=' would allow this.

Imagine an extended newspaper archive search done through a Web browser.
Say the archive-server would like to avoid showing you articles you have
already reviewed; and say the server stores articles by week.  As you read
an article, the server responds with a state-info header that says "within
path /week1, send state-info token w1a1."  The browser flits around the
archive and returns to /week1.  Rather than having to send one token for
every article reviewed (w1a1, w3a4, w5a7 ....), it just returns the
token(s) for week1.  The server modifies the week's index accordingly.

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.

I'm not saying this is optimal -- I'm happy with Dave's proposal as it
stands.  I am suggesting a potential middle ground.

M. Hedlund <hedlund@best.com>

Received on Saturday, 9 December 1995 15:57:08 UTC