Re: Issue 535 - viewing state for things removed from cache

Charles McCathieNevile wrote:

> I disagree withthe proposed resolution of issue 535. This is not really
> really simple, but I don't think it is really really complex either...


Hi Charles,

Thanks for being ahead of the curve on this one. <grin>

> A page may not be placed in the cache for a number of reasons. In the real
> world there are pages that actually change, so are not listed as cacheable
> and pages that do not change, but are served as uncacheable for no better
> reason than the site developer didn't bother changing the server default
> setting.
> 
> Browsers often cache pages anyway, for things like offline browsing, and may
> decide not to cache a page according to more or less any criteria at all.
> 
> So if a browser keeps a history, it should be able to get the page and be
> where one was when one left, if the page has not changed - as determined by
> the HTTP headers, or by the browser doing a diff against its cache for any
> developer who is really not very trusting and likes that much work.
> 
> If the page has changed, then it may not make much sense to keep the required
> information, since the user may need to know what has changed.
> 
> (there is an implementation issue of how much history and how much point of
> regard information should be kept - if there are 1000 pages in the history,
> which is what I like to keep, does it need to cover all of them, or is it OK
> to only keep it for the last 100?)


What about if the user configures the user agent to not cache more 
than, say 1M of data? If the user has visited a page recently, but
the page has been removed from the cache due to the user's memory
preferences, are you suggesting that the user agent track state 
information that is is no longer caching? Even if the answer to that 
question is "yes", that can't be done infinitely either. So at some 
point, the user may have recently visited a page and the user agent 
may not have state information stored anymore. It is for this case 
that the notes (not really a formal proposal yet) suggest that the 
UA is not required to restore state.

Note that this checkpoint does not require a history mechanism.
It starts:

  "For user agents that implement a viewport history mechanism..."

[One developer referred to a required history mechanism as a
  "history tax."]

This checkpoint requires UAs to store state information, but it
does not require user agents to store an infinite amount of
state information. I don't think that we should tell user agent
developers how to implement cache mechanisms, or how much to
cache (though user-configurable seems like a good idea). In this
light, it makes sense to me to say "When info is no longer in the
cache (that is implemented by definition for a history mechanism,
but UAAG 1.0 does not require a minimal size), state information
need not be saved."

  - Ian



-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Wednesday, 10 April 2002 20:55:15 UTC