Regarding Draft protocol-10




Section 10.1 of draft-protocol-10 explains briefly how paging should be supported by Collections. This section seems to have not been widely discussed (at least I couldn't find links to that subject) and I wonder if all the different perspectives have been taken into account.

Alternatively, Mark Nottingham has built an comprehensive proposal on that matter in:

I believe therefore we ought to consider the replacement of section 10.1 by a pointer to Mark's proposal which hopefully will become an accepted standard soon.


Replace section 10.1 as follow:

10.1 Collection Paging

Collections can contain large numbers of resources.  A naive client
such as a web spider or web browser could be overwhelmed if the
response to a GET contained every entry in the Collection, and the
server would waste large amounts of bandwidth and processing time on
clients unable to handle the response.  For this reason, servers MAY
return a partial listing of the most recently updated Member

The returned Atom Feed MAY NOT contain entries for all the Members in
a Collection.  Instead, the Atom Feed document MAY contain link
elements with "rel" attribute values of "next", "previous", "first"
and "last" that can be used to navigate through the complete set of
matching entries as defined in section 3. of RFC####.

You may argue that there is little improvement at first sight but I believe there would be a greater flexibility that way and also a much better definition for Feed paging.


Considering the fcat section 3 of Mark's draft follow the same naming as section 10.1 of APP-10 the impact should be almost none while providing a stronger definition of how to page collections.


This would of course require Mark's draft to be standardized before APP which is a risk to manage.

CategoryProposals CategoryProposals CategoryProposals