Re: caching dilemma

Shel Kaphan  <sjk@amazon.com> wrote:
| Kee Hinckley writes:
|  > At 10:20 PM 5/25/95, Shel Kaphan wrote:
|  > >To make the web work more smoothly, it would be nice if browsers would
|  > >handle this situation more gracefully, by, for instance, not displaying
|  > >errors like "Data Missing", but just automatically reloading the page.
|  >
|  > Automatic reloading of a page in my history stack seems rather
|  > user-unfriendly. I expect history loading to be fast and not go off over
|  > the net. I guess I could see it as a user-specified option, but...
|  >
| I definitely see your point -- as I see it we're talking about a
| "lesser of evils" situation.  When you "back up" to an expired page,
| there are only three things I can think of that could happen:
| 1. you see the expired document.
| 2. you see an error message and (if you interpret the message correctly)
| 	you can reload the page manually
| 3. the browser reloads the page behind your back.
|
| Well, as Lori Anderson would put it, "?Que es mas macho?"
| I guess I'd pick door number 1 -- but only for the case where you view
| the page with browser navigation commands, not explicit links.

Using a definition of history being that which actually happened, only 
(1) is actually correct.
This relies on the assumption that when I fetch a URL I want the URL at 
that point in time not, all URLs in future points of time.

|  > >document.  It is REALLY BAD for browsers to display cached copies of
|  > >expired documents when they are meant to be freshly displayed in
|  > >response to a direct user command, because a URL may be a request to a

I think consider the following case clarifies the issue (it did for me).
History is not kept off screen but each new URL creates a new window.
Going back through history in this model is simply flicking back in the 
window stack.
Given that the URL in question has been continuously visible is it 
appropriate to delete it / reload it just because it is now the top 
window, not the second top window.

- JonT

Received on Thursday, 8 June 1995 03:43:10 UTC