Re: Definitions: caches, history buffers, etc.

On Tue, 9 Jan 1996, Shel Kaphan wrote:

> Dave Long writes:
>  > 
>  > How's this sound?
>  > 
>  > A client or proxy cache:
>  > 	exists to model the origin servers' state (which was observed
>  > 	sometime in the past at t sub 0) at t sub now.
>  > 
>  > A client history buffer:
>  > 	exists to model the user's interaction history.  Hence use
>  > 	of the history list, or back button to return to a page
>  > 	with which the user last interacted at time t sub 0,
>  > 	should result in a state fundamentally similar to the one
>  > 	in which they were at t sub 0 (and forward should bring them
>  > 	back to t sub now)
>  > 
>  > Even if the server (and hence the cache) would provide different content
>  > for the URL at t sub now than it did at t sub 0, the history buffer should
>  > present the content at t sub 0.
> 
> Should, but doesn't *have* to, because history buffers, like caches,
> are finite and may have to discard objects in order to make room for
> new ones, and there's no guarantee you'll get the t[0] version again
> if you have to reload a discarded object.

The "exists to model ...." phrases come close to covering the concern
I raised. I think a combination of the earlier proposal and these
concepts would be real close to what I was looking for.  Perhaps if
'sub 0' where replaced with 'sub now-1' or 'now-n where n is <= the
number of entries in the history buffer' would be enough of a
clarification so we don't need to explain that 'should' is not 'must'.

> 
> ...............................................................................
> I could see maybe addressing the above in the HTTP spec, but it
> seems unwise to try to talk about the stuff below here (including my
> next comments) in the spec.

First, I almost agree with your   in/out line except that the
sentence below "Futhermore ... interaction" is a critial part of the
history buffer state from the user's interaction perspective.

> ...............................................................................
> 
> Counter-intuitively, a history buffer's heuristic for choosing pages
> to discard (to make room when it exceeds maximum capacity) might be to
> discard the freshest (i.e. longest time till staleness) pages first,

Not only counter-intuitive, but I think wrong ... 
1.  Once the history buffer is full ... discarding the most recently
    viewed material would be a performance and usability nightmare since
    every BACK would be delayed.
2.  Going BACK to recover a previous perspective would be impossible.
3.  I have an application which shows a list of objects upon which
    various operations can be requested via radio buttons.  One
    operation is DELETE. Going BACK with a refresh is distinctly
    uncomfortable since the refreshed object list doesn't show the
    deleted objects.  (I know since thanks to the Netscape 2.0
    bug/feature I get to experience such refreshes).

> as they are the most likely to be able to be reloaded later in the same
> condition as they were last time they were in the history buffer.
> Also, the last pages to be discarded should be those that were
> responses to operations that may have had side effects, as reloading
> them may require performing the operation with side-effects again.

We agree we are probably chating outside the scope of the protocol. But
I would expect a well designed browser user interface to warn me when
it found it necessary to refresh a page in response to a BACK request.
(NB.  The history buffer can be incomplete due to interrupted 
transfers .... I would prefer to approve a refresh in that case
as well).


> 
> 
> 
>   Furthermore, if there is state associated
>  > with that page, such as <FORM>s, Director Movies, Java Applets, etc., it
>  > should be restored so that the user is presented with the page in the state
>  > of last interaction.

As stated above, I believe the concept in this sentence is part of the
description of the history buffer.


. . . . . . . . . . . . . . . my line ...........

I believe what Dave Long raises here is an important User Interface
design issue whereby browser implementors can distinguish themselves.
And while I agree with the analysis, I don't think it needs to be
covered in the HTTP protocol.

>  > 
>  > There's a third concept that hasn't been touched upon - the distinction
>  > between global history and the history buffer.  I feel pretty strongly
>  > that the history buffer strongly implies consistency with the user's
>  > navigational clickstream, so if there are multiple windows available,
>  > and the following sequence occurs:
>  > 	Page A displayed in window 1
>  > 	Page B displayed in window 2
>  > 	user follows link to C in window 2
>  > 	Page C displayed in window 2
>  > 	user follows link to D in window 1
>  > 	Page D displayed in window 1
>  > Use of the Back button in window 1 can result in either:
>  > 	a) Page A displayed in window 1
>  > 		-or-
>  > 	b) window 2 raised to the top, still with Page C
>  > 		-but not-
>  > 	c) Page C displayed in window 1
>  > 

Dave Morris

Received on Wednesday, 10 January 1996 08:13:32 UTC