I wrote: > > I wasn't so much referring to the conflict resolution part as the > > other sync metadata. Once piece that's really useful is the > sx:sync/@updates > > attribute--it's simpler and more reliable than a timestamp for > detecting > > updates. If you really only care about one-way (aka publish only) > sync, > > then your FeedSync implementation becomes that much simpler.
James Snell replied: > I'm not convinced about the "more reliable" part. If app:edited > elements are used properly, they would seem to be more than sufficient. > I'm curious if you have specific examples of where using the timestamp > breaks down? > > - James Timestamps are problematic for sync because they assume that you can synchronize clocks across different machines. You also have to do things like convert between timezones which doesn't work well in practice. There are problems for the publish-only case as well as bidirectional sync. On a single machine, reported time values don't always move forward linearly when your clock resyncs against some time authority, and of course because of daylight saving time. Or your AtomPub "server" is really a server farm, and you make successive edits that are server by different machines who's clocks are offset. We still have a timestamp in sx:history for use as an approximate time value. We also use it as a tiebreaker in the case of conflict, but only to decide which edit goes on the "outside". We use sx:sync/@updates as the primary way to detect updates and conflicts. I think that makes sense when you consider that our primary design point was around making sync work for many scenarios, and not just deleting previously published items. Steven
