Re: Tombstones

[James M Snell <jasnell@xxxxxxxxx>]

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