James M Snell wrote:
-1. While we may not all agree on the specifics, I believe the ability
for the client to request specific subsets of entries is going to be
necessary. I definitely agree with the concept of GET'ing the feed
from the collection URI as you suggest and with using the next link
relation, but we should not toss out list-template completely.
Why couldn't it be done in an extension?
Atom-Format wasn't official that you already proposed a bunch of
extensions. Recently, whereas Atom-Format is only a few months old, we
started talking about first/previous/next/last link relations (another
extension to Atom-Format) as they seem to be needed by Atom-Protocol
(and others, such as OpenSearch) and will then quickly be widely deployed.
Why couldn't we envision list-templates as an early extension?
List-templates are definitely useful, but not necessary for
Atom-Protocol. Why not adding RFC3229 w/ feed in Atom-Protocol Core? It
seems better than list-templates for syncing as a server will give you
exactly what you need, and we wouldn't even have to discuss about
atom:updated vs. app:modified. I prefer leaving it for an extension, as
well as list-templates.
Would you be +1 if the Pace would only add the ability to GET the
collection URI using atom:[EMAIL PROTECTED]"next"] paging? I can split the Pace
in two Paces: add the GET to the collection URI, and remove list-template.
--
Thomas Broyer
