Eric Scheid wrote:
Just one more problem (read: ambiguity) ... from what end does the offset work?For example, given a {begin} of 2005-10-01 and an {end} of 2005-10-31 one might find that there are 100 matching entries. If {count} is "20", then which entries are returned when {offset} is "0"? a) the 20 entries at the 2005-10-01 perimeter b) the 20 entries at the 2005-10-31 perimeter
Logic would dictate that an offset of 0 would refer to the "beginning" of the set (i.e. option a). It's also the only sensible direction in which to process a multi-page list without the risk of losing items. However, it probably wouldn't harm to make that clearer.
The question I have is why the need for the app:seek attribute? Would it not be simpler to just predefine the exact format of the query string? Or is that template also meant to serve as a demonstration of the server's capabilities? If that's the case, then some text to that effect might also be useful.
One other thing. How well does this extension deal with the issue of "insignificant" updates (i.e. changes to an entry that don't result in an atom:updated increment)? Would it not be better to track the last modified date of an entry (whether that is some internal value or an extension element still to be defined) rather than the atom:updated date?
Regards James
