James M Snell wrote: > 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.
I wouldn't be so pessimistic; I think eventually servers will all implement something like this. > 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. Obviously this little detail isn't a deal-breaker, but I think it makes sense to use the same syntax as <atom:feed>, <atom:entry>, and <atom:source> (meaning an element instead of an attribute)--especially if we are going to have <atom:updated> and/or <app:edited> and/or <atom:source> nested within it. > >> 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. In particular, without the timestamp(s) it is hard to see how the tombstones fit in with feed paging and date-range-based queries. > >> 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. If you trust the aggregator, then you can have a policy of matching tombstones and entries by (source, id). If you don't trust the aggregator, and you really need to verify the entry was deleted, then you can use the source metadata to look at the original feed to see if it contains the tombstones or not. > > 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. I agree the id attribute/element choice doesn't really affect what atom:source means inside a tombstone. - Brian
