PaceServerCollectionSubsets

[Ezra Cooper <ezra@xxxxxxxxxxxx>]

PaceEntryQuery is a good start on the semantics of client-specified 
subsets--but what about server-specified subsets? I've thought about it 
a bit and drafted PaceServerCollectionSubsets.

I believe we should make it clear that the server MAY return a 206 
(Partial Content) response even if the client did not ask for a subset. 
In that case, I believe clients will want to know what they got so that 
they can form a follow-up query.

In a nutshell, the proposal is: When the result of a collection request 
is too large, the server should use the modification date and always 
return the most recently modified items (how many is up to the server). 
Because clients know what they got, they can request the next few items 
in that sequence. Note that, for this particular situation, I'm 
proposing a standardized field to order the collection, and that we 
always proceed from most recent to least recent.

This may seem particular and inflexible as a general query language, 
but if we think of it instead as a syncing protocol, it serves 
precisely the need: a client just wants to know, "Which items should I 
GET? Which items have changed since the last time we talked?" The 
proposal allows the client to iterate over the most-recently-modified 
items until it reaches the date at which it last sync'd. At that point 
it knows it has a complete list, up through the time when it made the 
first request.

This doesn't conflict with allowing clients to specify ranges over an 
arbitrary field. This just sets the understanding when a server returns 
less than what the client requested.

Thoughts?

Ezra