On 11/6/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
>
> 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.
>
It just looks at atom:updated.
> >> 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
>
I am still not sure what you are getting at.
> >> 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.
>
No. I understood. I don't think it is a problem.
It was not a significant update. You don't need it
until you go to edit the entry.
> 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.
>
I have thought about this.
I would queue these things up in another feed ("collection")
or use an extension or consider all updates significant and
enforce updating 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?
>
By updated or get as many as you are displaying to
the user at a time.
If you are loading up your shiny new laptop to do some
editing on the plane, you may want to load em all.
> >> 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.
>
Per my statements above, I don't think it is.
- Luke
