Re: Tombstones

[James M Snell <jasnell@xxxxxxxxx>]

James Holderness wrote:
> 
> Brian Smith wrote:
>> Ha. I already implemented it too, but I used the updated syntax that
>> James suggested on his blog (http://www.snellspace.com/wp/?p=818).:
> 
> I chose the original syntax because for me it's an order of magnitude
> easier to implement. And since I doubt I'm going to see any server
> support for this either way, I might as well go with whatever is easiest.
> 

FWIW, I have no real preference for either of the two syntaxes so long
as we have a way of expressing the atom:id, a timestamp and possibly a
source.

>> I think this way makes it clearer how to handle cases where an entry was
>> added, we saw it, the entry was deleted, we saw a tombstone, and then
>> the entry was undeleted, and we see the entry again. In order to support
>> undelete, we need to be able to order tombstones and entries by date.
> 
> If you're undeleting something, just remove the tombstone from the feed
> and add the entry back.
> 

+1. The timestamp can still be useful when dealing with more complex
sync use cases.

>> This new syntax also makes it possible to specify a <source> of the
>> tombstone, which is needed when dealing with aggregated feeds,
> 
> I was thinking about that too. I don't see how you can possibly trust a
> tombstone in an aggregate feed. Still, there's nothing stopping you
> including a source element (or whatever other metadata) in the original
> syntax.
> 
> <x:deleted-entry id="xxx">
>  <atom:source>
>     ...
>  </atom:source>
> </x:deleted>
> 

This works. Tombstones in aggregated feeds definitely need to be
carefully considered.

- James

> Regards
> James
> 
>