- From: David W. Morris <dwm@shell.portal.com>
- Date: Tue, 9 Jan 1996 23:58:53 -0800 (PST)
- To: Shel Kaphan <sjk@amazon.com>
- Cc: Dave Long <dave@navisoft.com>, http-caching@pa.dec.com
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