RE: Tombstones

[Steven Lees <Steven.Lees@xxxxxxxxxxxxx>]

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.

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...

> The "by" endpoint label is supposed to be user-readable but unique;
> that
> seems difficult to achieve. I would like to see some advice on how to
> achieve this, especially in the case where one authenticated user has
> multiple endpoints (say, two phones, an in-office desktop machine, and
> a
> large pool of laptops).

I discussed that recently here: http://blogs.msdn.com/stevenlees/archive/2007/12/02/about-a-by.aspx. The short answer is that "by" is not really meant to be user readable. For that we'd recommend atom:author or something else in your data model.

> > 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.

Steven