RE: ACTION-811: Send a summary of the pagination note (3.1.4) to the mailing-list

The sub-pages of a paginated original page are a representation of an original resource, which itself may have an expiry time. There is nothing to prevent an end user from reading a resource (or part thereof) that has expired, and the reading of sub-pages from an expired resource is acceptable. You have to give the end user time to perceive the entire original resource, even if this means navigating through (expired) sub-pages.

What might be of use is to flag to the end-user that the sub-pages are derived from a resource that has since expired. The user would then have the choice to refresh (and probably return to page 1 of N) or continue to read the sub-pages.

In practice we don't see this as a typical problem.

---Rotan.

-----Original Message-----
From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Francois Daoust
Sent: 16 July 2008 14:43
To: public-bpwg-ct
Subject: ACTION-811: Send a summary of the pagination note (3.1.4) to the mailing-list


Hi,

During last call, I agreed to take the discussion to the mailing-list, 
so that we can have everybody's view on the matter.

This is about section 3.1.4 "Serving Cached Responses" of latest draft:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080712#sec-serving-cached-responses

... and the possible link between pagination and cache directives.

Pagination of a page is (probably) done on a regular basis by CT-proxies

Let's suppose an origin server serves a page with a cache expiration 
time of "10 seconds". If the page gets paginated by the CT-proxy, then 
when the user requests the second/third/... page, the expiry time is 
likely to have elapsed. Should the CT-proxy re-request the resource on 
the origin server?

The point was made that it is in practice impossible, because there 
would simply be no guaranteed way for the user to "view" the subsequent 
pages of a resource with a low expiry time. Nothing guarantees that the 
new resource would get paginated the same way, and nothing guarantees 
that the new resource will not be completely different from the previous 
one.


My personal take on that:
- a request for a subsequent page in a paginated page is a "scroll down" 
when one browses on a regular desktop browser (or, identically, a move 
to the next card in a WML deck).

- I'd remove section 3.1.4 altogether: first paragraph on respect for 
caching directives is true but out of scope in a way since we don't 
really need to address the "caching" part of the CT-proxy.

- If we keep section 3.1.4, I'd complete it with:
"Requests for a subsequent page of a previously requested resource 
should not trigger the renewal of that resource, even if its expiry time 
has elapsed."

Any other thoughts?

Francois.

Received on Wednesday, 16 July 2008 14:12:58 UTC