Brian Smith wrote: > You make a good point. But, if there are frequent deletions then > non-FeedSync-aware clients will have to wade through "This entry has > been removed" entries showing up to replace entries that they have > previously marked as read or otherwise filed as "don't show me this > again unless it is updated".
As a publisher, you have to consider two kinds of clients: those that don't understand deletions, and those that do. If you *really* want to make sure that information disappears from any client aggregator, then the most reliable way to do that given the state of the world today is to issue an updated item where the new fields are either empty, or have some message like the one you suggest below. If you just want to provide deletion as a feature for those who are willing to upgrade their feed client, then you can go with either tombstone method. > Consider this alternative formulation: > > <entry> > <id>id of the original entry</id> > <updated>deletion date</updated> > <title>This entry has been removed</title> > <summary>This entry has been removed</summary> > ... > </entry> > <sx:deleted> > <atom:id>id of the original entry</atom:id> > </sx:deleted> > > This accomplishes your goal, but makes the "low tech tombstone" > optional, for cases where asking clients to navigate "This entry has > been removed" entries is inappropriate. It does require the server to > insert <xs:deleted>, though. This is approximately what we do in FeedSync. You add (or change) sx:sync/@deleted to "true", and any client that is aware of that attribute will recognize the deletion. Publishers can choose to alter the entry, or not. > The FeedSync mechanism is reasonable if only a few entries are > occasionally deleted. But, it is not reasonable in other situations. In > particular, in WLW I save all my drafts on the server and often delete > drafts without publishing them. I don't want to see a bunch of > tombstone > entries in the article list. The Snell mechanism would be more > appropriate in that scenario. > > - Brian That doesn't seem like a good example. If your drafts are never published in a feed, then you don't ever need to tombstone them in a feed. But that kind of scenario (having downlevel clients who never care about seeing deletions) is why our default on http://feedsync.mslivelabs.com is to omit tombstones from the feed. Since any client that wants them is already doing some extra work, it's easy enough for that client to opt in to tombstones as well, via a query parameter or HTTP header. Steven
