Comments below. Steven Lees wrote: > Brian Smith wrote: > >> The main issue I have had with FeedSync is that deleted entries look >> like "live" entries for every consumer that doesn't understand >> FeedSync. >> This means that you cannot use FeedSync unless all clients are >> FeedSync-aware. James idea of using an extension element solves this >> problem nicely. > > This issue came up in the August AtomPub interop. Our current solution > on http://feedsync.mslivelabs.com is that, by default, the server doesn't > give you tombstoned entries. You have to ask for them with a query parameter. > I've also been hunting for the right HTTP header to ask for tombstones as an > alternate mechanism. >
Such mechanisms are only necessary if you overload atom:entry. Using something like x:deleted, there's no reason a client would have to do anything special to get the tombstones. > James's suggestion of using a different element is another reasonable > solution, > but I think it introduces problems as well. More on that a little later... > Definitely please do post your thoughts on that. > [snip] >>> We considered a separate spec for tombstones >>> that was independent of the other sync extensions. >>> It didn't seem worth it given the benefit of having >>> all of the sync-related extensions in a single, >>> coherent spec. If you want spam control, chances >>> are pretty good you want one-way sync, and at that >>> point you want more than just tombstones. >> In a single-user blog, where the user is editing the blog in both a >> blogging client and in the blog's web interface, the blogging client >> should be notified (via the feed) when the user deletes an entry using >> the web interface. A simple tombstone mechanism is sufficient for >> handling this, because none of the conflict-resolution stuff is >> necessary. > > 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. > 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
