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

Charles McCathieNevile wrote:

 > There is no necessity for a user agent to implement a cache in
 > order to implement a history mechanism.

I am beginning to understand your point: local cache is one
thing, history is another. A user agent could have an empty
local cache (in terms of page content) but save enough information
to know that the results of a GET will return content that has
not changed since previous state information established. Therefore,
the UA could restore the old state information even though the
local cache had been emptied.

Some of this is discussed in section 13 of the HTTP/1.1 spec [1].
For instance:

  "13.3.1 Last-Modified Dates

   The Last-Modified entity-header field value is often used
   as a cache validator. In simple terms, a cache entry is
   considered to be valid if the entity has not been
   modified since the Last-Modified value."

   [1] http://www.ietf.org/rfc/rfc2616.txt

So the UA could save (server) dates along with state
information and compare to the last modified date of
a GET response. If the last modified date was earlier,
the state information is presumably still valid.

There are undoubtedly additional HTTP/1.1 mechanisms
(like etags, expiry header, max-age) but I am no
HTTP or cache expert.

Perhaps this is a reasonable expression of what Charles
would like:

    "These state variables must be restored whenever
     the content has not changed since the most recent
     setting of the state variables."

It is implied (as usual) that the user agent must be able
to recognize that the content has not changed (by available
HTTP mechanisms or other mechanisms for other protocols).

I've written the above sentence in the passive voice to
allow for the case where selection/focus/point of regard
is set by program, not the user.

So, in light of Tantek's request for clarification, do
we set the stronger expectation for restoring state
variables?

While somewhat hesitant, I support the addition of the
above sentence. The checkpoint does not require implementation of
a history mechanism. The implementation burden of storing
information that allows the UA to know whether content has
changed since the last GET seems quite small.

Comments from developers?

By the way, I'd like to change the title of this checkpoint
from "Restore history" to "Restore viewport state history"

Thanks,

  _ Ian

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

Received on Friday, 12 April 2002 17:34:18 UTC