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.

> Example: we have a feed with two entries. There are two feed reader
> clients, neither of which know about tombstones.  Client A requests the
> feed and sees both entries.

<snip>

> Client A gets the feed and still sees two entries, one of which is
> marked as being updated.
>
> Client B comes along and requests the feed and see two entries, both of
> which are new to it but one of which doesn't actually exist.  Why
> should
> Client B have to see that entry at all?  If the entry was deleted, it
> shouldn't be in the feed.

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.

> Now use the separate tombstone element,
>
>   <feed>
>     ...
>     <x:deleted>
>       <id>tag:example.org,2007:1</id>
>     </x:deleted>
>     <entry>
>       <id>tag:example.org,2007:2</id>
>       ...
>     </entry>
>   </feed>
>
> Client A continues to operate as it always has when an entry that was
> once in the feed suddenly isn't and Client B never has to see the
> deleted entry at all.  That makes a whole lot more sense to me.
>
> Now, Steven indicates that their implementation will not include the
> tombstone by default. Clients that want tombstones would have to ask
> for
> them explicitly.  While that would solve the problem, using the
> tombstone element would avoid the need to have that kind of negotiation
> mechanism at all.

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.

Steven

Reply via email to