On 6/11/05 3:23 PM, "Luke Arno" <[EMAIL PROTECTED]> wrote:
> Client grabs start of feed and follows next until it sees stuff > it already knows about or has enough. How does it do that test? Does it just look at atom:updated, or does it need to do a complete comparison of every element, remembering of course that the entries in the collection feed may be an abbreviated representation of the full entry. >> 1) ignore the order of the entries within any given feed document > > I am not sure what you are getting at. This means you can't optimise your comparisons by looking at the last entry in the feed document >> 2) entries can be modified without changing the atom:updated element > > You GET before you PUT. When offline things may fall > out of sync no matter what you do. You are off line. > You missed the implication: if atom:updated isn't changed then that entry won't appear in the collection feed (sorted by atom:updated) amongst the other recent updates. You have to keep traversing to find it. However, I do see where you are coming from, but I just realised another problem, one it appears you haven't ... how would I know that an old entry has been modified by another user if they don't touch atom:updated? Imagine I'm an editor or a moderator, and it's my job to make sure no one tries slipping big changes (or spam) into the system by leaving atom:updated untouched (eg. on a wiki) ... if my APP-client can sync with the server, including minor changes, then my client can alert me to those entries that were minor-modified, distinct from those that were atom:updated. So, sure, when I want to PUT my edits to the server, I'd do a GET first, but how do I know which entry I want to undo some edits on in the first place? >> 4) retrieving the entire collection, going back possibly hundreds of pages, >> would/should also be considered wasteful > > Retrieve what you are going to need. What is your concern? > How do you know when to stop traversing back? >> 5) it should just damn work, >> > > What doesn't work? Traversing back through a collection whose members are sorted by atom:updated can result in entries with minor changes being missed if the client stops once it sees entries matching what it has on hand. That's broken. e.
