Re: Definitions: caches, history buffers, etc.

David W. Morris writes:
 > > 
 > > 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.

That's not what I said.  I said "longest time till staleness", not
"most recently fetched".  

 > 2.  Going BACK to recover a previous perspective would be impossible.

Eh?  Making that maximally possible was the point.  We want to maintain in
the history buffer the things that would be the most difficult to
reconstruct in the same condition later.

 > 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).
 > 

I think we're just miscommunicating.  I agree with what you're saying
-- the heuristic I suggested is just one of probably many that would
be OK (though I don't think you quite got what I meant).  The point I
was trying to make is that the heuristics for discarding from history
buffers are quite different from those for caches.

 > > 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.

Indeed -- though there are cases where it shouldn't be necessary,
e.g. when the page to be reloaded was gotten with a GET and the result
was cachable.

 > (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.
 > 
OK.

--Shel

Received on Wednesday, 10 January 1996 22:35:18 UTC