Re: PaceEntryQuery

[Robert Sayre <mint@xxxxxxxxxxxxxxx>]

Ezra Cooper wrote:

> A couple of questions and suggestions on PaceEntryQuery:
>
> Greg, why does it say that range specifiers apply only to Atom Entry 
> collections? I think we need SOME subset-fetching mechanism for other 
> Atom collections, don't we?

I wrote the range section. I agree that we need such a mechanism for 
other collections. I thought I'd try to solve it for entries first, then 
see what we can apply elsewhere.

> On allowing multiple ranges in one request: Is it necessary? Isn't it 
> just as easy to make multiple requests? Can we simplify the protocol by 
> dropping that?

Hmm. If we dropped the multiple range section, it would make the spec
simpler (by a little), but writing a client that retrieved multiple 
ranges would be harder. Does it impose a large burden on server 
implementors?

> Also, I would prefer to define ranges according to the value of the 
> field, rather than by ordinal ranges.

It's not a range request in that case. I can see the value in working
from a date, but a date range doesn't help you if you want 20 entries.

> Consider what happens if Alice 
> asks for items 0-9, then Bob inserts a new item 0, then Alice asks for 
> items 10-19. Alice will fetch an item twice. 

Alice also gets the total number of entries with each range request.
Ah... the ranges-specifier outlined in the Pace doesn't talk about
behavior for If-Range or Content-Range. I'll update it.

> If after the first 
> operation, Alice sees that the oldest item in that set was dated 
> 2004-09-03T12:37:42Z, she can then make a request asking for the 10 
> items immediately prior to that date. If Bob adds a new item, its date 
> will be outside that range, and won't affect the results.

Yes, but if Bob edits an old item, what happens? Remember, the only
required field is atom:updated. I don't think there's an approach we can 
take that will ensure the client always has an accurate representation 
of the server's state.

Hmm. I'm curious about the use case here. Is this aiming for sync
behavior? Existing APIs indicate that the most important thing to
provide is the last N things edited. Don't need a date for that. Where
does the rest come in?

> I'll devise a syntax for a range over date values. Would it be 
> reasonable to drop support for ordinal ranges?

Seems like you are looking for a query. N items since DATE is
not a range. A range would be

startDate - endDate (how many entries is this??)

If you want to limit the results returned, you have a search query. 
There's no Partial-Partial-Content.

Robert Sayre