Thomas Broyer wrote:
"app:modified" is The Simplest Thing That Could Possibly Work.
To restate my position - app:updated as defined in Atom isn't a suitable
signal for a sync protocol. Some other concerns:
- app modified won't work for what you want without app:modified-since.
- I'm not sure you can get sync to work via an intermediary document
instead of direct with the resource.
- we don't say you have to use POST to sync with a resource in any case.
All the suggestions I've heard so far seems pretty fragile to me. Much
of that fragility comes down to asking one resource for the state of
another and hoping things will work out. I know we like "simple" things,
but client/server synchronisation might require us to accept some
inherent complexity to get to a useful solution. "Sync is difficult so
we didn't take it on" is a perfectly good position for the WG.
We agreed a long time ago that resource DELETE did not require state
synchronization in collections. DAV had to fix their spec for the same
issue. I see a sync via introspection requirement as introducing the
same class of issue.
Here's some food for thought: the duplication of resource http headers
in lookup resources is an antipattern we need to manage down. That would
be "DRY", given our propensity for using slogans in place of technical
debate.
Job one is to decide whether sync is scope *at all*. Instead of arguing
about implementation details like clocks v tokens. I'd like to see that
settled first.
cheers
Bill
