Steven Lees wrote: > James Snell wrote: > > > Using the x:deleted tombstone element, on the other hand, the spam > > entry only shows up once, at a maximum. Readers that do not > > understand the tombstone element would act no differently than they > > currently do and users should not see any change in current feed > > reader behavior. > > The "spam-shows-up-more-than-once" idea is not correct, > regardless of which tombstone mechanism you use. Even if you > hand tombstoned entries to a non-tombstone client, the entry > only shows up once. If, as we're recommending, you only give > tombstones to clients that ask for them, then there's no entry at all.
What I meant was, first the spam will show up, the user will mark it read, then the feed reader will see the tombstone, which looks like an updated version of the original entry, and then mark the entry as new/unread, and then the user will have to mark it (the tombstone) as read. The only way to hope to prevent this in FeedSync is to ensure that the atom:updated value is not updated when the entry is converted into a tombstone. But, that causes problems when other specifications (e.g. RFC 5005) require that entries be paged/ordered by their atom:updated property. > Agreed. But with the <x:deleted> element, you're still > passing unnecessary info to the client. If you go and delete > ALL of the entries from the feed, then the client receives a > feed with nothing but tombstones, which it didn't want in the > first place. In that case, asking the client to opt-in seems > like a pretty good idea. But, with the Snell mechanism, the tombstones are invisible to every client that doesn't understand them. So, they might be bloating up the feed (slightly), but it is almost guaranteed that they won't be visible in the UI. > Again, the mechanism seems pretty simple to me, and it has > the benefit of not passing any tombstones to a client that > won't understand them anyway. Sure, but: (1) Many (most?) AtomPub applications will not significantly benefit from FeedSync except the tombstone mechanism (because FeedSync and AtomPub each have their own synchronization protocols). When I look at the FeedSync spec, I see a lot of stuff I don't really care about. It feels wrong to implement only the tombstone part of FeedSync when that isn't even its primary feature, but I'm not going to implement the whole spec just to feel comfortable using its tombstone mechanism either. When I look at James' tombstone mechanism, I see exactly what I need. (2) James Snell's mechanism can be implemented in existing feeds without causing any problems whatsoever; it is an almost zero-cost solution. (3) Using a query parameter to control the tombstones does not fit with the "RESTful" design AtomPub and other Atom-related standards. Unless you change the opt-in mechanism to one of the following, you will never be able to win over the hardcore Atom crowd, and another mechanism will be chosen instead: (a) an HTTP header (perhaps Accept:, like I mentioned in another post) to request FeedSync annotations within a feed, (b) an atom link relation to link to a FeedSync-annotated feed, or (c) an IRI-template-based mechanism for discovering the FeedSync-enabled feed. (These are listed in order of my personal preference.) (4) FeedSync could be easily adapted to use James's mechanism [1], or both mechanisms can coexist. Personally, I am willing to implement the FeedSync mechanism if it is requested via the Accept: header, or if there is otherwise consensus to use it. Otherwise, I strongly prefer James Snell's solution (the <x:deleted><atom:id>...</atom:id></x:deleted> variant) because it is so unobtrusive. In fact, I could implement it in a half hour if we could agree on a namespace to use for it (preferably one without the word "tombstone" or other references to death). - Brian [1] http://www.snellspace.com/wp/?p=818, starting with "Here's a modified take"
