- From: Shel Kaphan <sjk@amazon.com>
- Date: Tue, 9 Jan 1996 16:16:01 -0800
- To: Dave Long <dave@navisoft.com>
- Cc: "David W. Morris" <dwm@shell.portal.com>, http-caching@pa.dec.com
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. ............................................................................... 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. ............................................................................... 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, 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. 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. > > 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 --Shel
Received on Wednesday, 10 January 1996 00:33:47 UTC