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
