Quoting James M Snell <[EMAIL PROTECTED]>:
http://www.snellspace.com/wp/?p=818 - James
1. Deleted entries (aka Tombstones) are indicated by extension elements contained within the atom:entry element. For clients that do not understand the SSE extensions, these will appear no different than any other entry such clients would have no way of knowing that the entry was deleted. Also, this solution assumes that there is still enough data in the database to reconstruct the deleted entry in the feed. The content, title, tags, etc may all have been removed from the database.
I disagree. Having clients that don't understand the extensions processing them in the same way as updates to the entries seems like a massive plus-point for FeedSync to me. I assumed that you aren't supposed to reconstruct those items, after all you are trying to delete the item. The tombstone entry would look something like this: <entry> <id>id of the original entry</id> <updated>deletion date</updated> <sx:deleted /> <title>This entry has been removed</title> <summary>This entry has been removed</summary> ... </entry> If the client supports sx:deleted it can remove the entry from its store, if the client doesn't support sx:deleted, it will replace the old entry with this low-tech tombstone. If the client is a framework, sub-clients will have the opportunity to implement sx:deleted, even if the framework doesn't. A publishing client that understands sx:deleted could delete an entry in this way on any arbitrary atompub server. There is very little coordination cost - you can use it today and wait for the rest of the infrastructure to catch up. The feed + stream of entries model is the 'protocol' of how feeds work. FeedSync is backwards compatible with this protocol; your alternate proposal seems to require a boil-the-ocean from publishing clients, atompub servers, intermediaries, feed servers, aggregator frameworks, and aggregators before these tombstones will work. Why create a new protocol when we can use an existing one? -- Dave
