- From: Ian B. Jacobs <ij@w3.org>
- Date: Fri, 12 Apr 2002 17:33:47 -0400
- To: Charles McCathieNevile <charles@w3.org>
- CC: WAI UA group <w3c-wai-ua@w3.org>
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