Eric Scheid wrote:
On 11/7/06 8:14 PM, "Bill de hÓra" <[EMAIL PROTECTED]> wrote:
- app modified won't work for what you want without app:modified-since.
I missed this. I assume app:modified is some element in either an entry
document or the collection feed, is that right? Can you walk through a
simple case that shows the need for app:modified-since?
The non-existent app:modified I imagine will be keyed off a physical
clock, not a logical one. Unless the intention is to store the server
value as is, which at that point, Robert is correct in his assessment re
using tokens, except these will have a date based cmp().
Fine, the client will be able to assess if the resource has changed.
Now, how does the client know the latest app:modified in fact reflects
the last modification and is coincident with reality?
An app:modified value obtained via a collection is not assured the
reflect the state of the resource. Unless we say it has to, which means
collections and entries are tightly bound, as was the case I mentioned
with DELETE, which we and the DAV people have thrown out as a flawed
design. Every request to a collection then requires it to check the
state of the entries. My belief is that metadata about a resource in a
collection is hearsay. You can't rely on it to make decisions about
resource state. Worse, never mind the scaling/caching issues, it's a bad
design, *because it doesn't solve anything*. I'll explain why further on.
An app:modified value obtained via the resource direct is assured the
reflect the state of the resource, assuming we spec that element in.
I'll argue that's an inefficient and incomplete reinvention of
conditional GET one layer up. In any case Conditional GET is not what is
needed. what is needed is conditional PUT/POST. Sync is only one half
of the problem for editing because the sync before update pattern is an
optimistic concurrency design, which gives you limited guarantees about
data loss. Really stopping data loss means the server has make the check
at the write operation, and then inform the client to pick up the latest
and greatest. One way around that is to have the client send a
modified-since value except it's for writes not reads. We are back to
conditional requests where the server has to trust the client.
I have a doubt that people who want sync actually want best-effort
against data loss. Merge semantics sure, but not lost updates. Tho' at
the moment, I'm playing fetch me a rock out of courtesy, since those pro
sync haven't said what they want to achieve, assuming I have't missed
it. I'd appreciate it if some design intent was brought to the table.
cheers
Bill
