On 11/6/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
>
> On 7/11/05 3:34 AM, "Luke Arno" <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> Wrongity wrong wrong wrong.
>
> a) if the collection feed is sorted by atom:updated, then recent changes
> which didn't touch atom:updated fall behind in the queue and become hidden.
> This is a broken concept of "sync", so please don't try redefining sync to
> mean that.
>
We have been through this before. I don't think you
need to sync with insignificant updates in most cases.
This is a job for extensions, if you have a special case.
> b) if the collection feed is sorted by app:modified, which is not present in
> the collection members, then lots of *significant* changes might be missed.
> This should be totally unacceptable, even to you.
>
Yeah. If. Is that an 80% case?
Even to me, aye? C'mon. Try to play nice.
> I'll post an example to prove this in a moment.
>
> >>>> 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.
>
> You have a funny way of showing you understood: answering my concern with an
> answer to a different question.
>
No. I don't think this is a problem.
Not seeing insignificant updates until a GET for edit
or update works for me and (I believe) in most
cases.
Just because you don't like my answer does not
mean I was reading the wrong question.
> > It was not a significant update. You don't need it
> > until you go to edit the entry.
>
> Don't tell me I don't need it. I host a wiki, I know I need it.
In the general case, it is not needed.
> app:signficant (or whatever) is set according to human judgment, and humans
> lie. Vandals and spammers especially so.
>
> I need it to know whether I need to go edit that entry or not.
>
I have suggested alternate solutions to you.
> Also, please stop redefining significant to suit your argument. The context
> here is regarding atom:updated, and whether the publisher considers the
> change significant to bring to the attention of the audience it is
> publishing to. It does not mean that the publisher considers good spelling
> as insignificant, it does not mean that the editors time is insignificant
> (it's quite possible it took him over an hour to fix one broken URL in a
> minor foot note).
>
Try not to put so many words in my mouth at once.
> >> 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.
> >
> > a) I would queue these things up in another feed ("collection")
> > or b) use an extension or c) consider all updates significant and
> > enforce updating updated.
>
> a) so I have to look in two places for changes? and how would that look in
> the introspection document, assuming we even have one?
Not a hardship IMHO.
> b) so my APP-client may or may not work with your APP-server? gee, thanks.
Huh? Based on what?
> c) as a publisher this is unacceptable. I am not my audience.
>
I have no way to know what you mean by that.
> >> 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.
>
> I see I'm going to need to draw you a diagram, or at least flesh out an
> example. See a following message.
>
Gee thanks, professor.
> > If you are loading up your shiny new laptop to do some
> > editing on the plane, you may want to load em all.
>
> All 10,000 entries. No, I don't think so.
>
You *may* want to. Or maybe you tell your client to
load up everything from the last month. Whatever you
need to take with you. You decide. This is true no
matter how you sync up.
> I'm not exaggerating there either. I monitor one source which so far has
> 11,132 entries as of today, and another with 38,462 entries.
>
> If I have a plane to catch I'm not going to want to download all those,
> especially if they haven't even changed.
>
So get as many as you want. My point is that is
when your client knows to stop. Tell it what you
need and it gets it for you.
> >>>> 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.
>
> sync would be leaky, not actually syncing all entries. leaky = broken.
>
Broken is when something does not work as
intended. If not syncing with insignificant updates
is the intended behavior, nothing is broken.
A leak is when something gets out that was not
intended to get out. Your terms are based on
intentions that I do not share with you.
> Also, from the users p.o.v., when reviewing a collection of recent changes
> and seeing some minor foobar that needs fixing, and doing the effort to fix
> those changes (including looking up the proper spelling, searching for an
> alternative URL for a broken link, etc etc), only to later find out that not
> only did someone else already do those fixes, but did them before I even
> synced, that would make me want to do violent things against whoever thought
> a leaky sync is sufficient and not a problem.
>
Boy, that was a bad move on you or your client's
part. You should have done a GET (click "Edit"
button or whatever) before you went to all that
trouble. What a waste.
If I change a bunch of code that I checked out a
week ago and don't do an update first, only to
find out that someone else made those changes
3 days ago, that would be my fault. I wouldn't
blame it on CVS.
- Luke
