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.
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.
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.
> 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.
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.
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).
>> 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?
b) so my APP-client may or may not work with your APP-server? gee, thanks.
c) as a publisher this is unacceptable. I am not my audience.
>> 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.
> 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.
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.
>>>> 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.
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.
e.
