James Snell wrote: >John Panzer wrote: >>>[snip] >>> The challenge is knowing how long to keep the x:deleted-entry things >>> around in the feed. >> >> Perhaps it's sufficient in many cases for the feed to indicate to >> consumers how long it keeps deleted-entry items around. Then a consumer >> who checks back, finds that they may have missed a tombstone, has the >> option of doing a complete sync by paging back through the feed history. >> > >One idea I had was that a feed would only contain deleted-entry elements >for entries that fall within the same atom:updated date range as the >atom:entry's in the feed. That is, if the deleted entry *would* have >appeared in a particular feed page based on it's app:edited or >atom:updated value, then there would be a deleted-entry element. The >downside of this would be that deleted-entry elements would be spread >out across multiple feed pages. I'm not sure if that's a really bad >thing or not.
That actually seems like a good thing, because it means that the deleted items will be in the "right" place in the feed. Anyone who wants the complete update will need to read all of those pages eventually. For SSE (spec is on http://msdn.microsoft.com/xml/rss/sse), we've been thinking that a sync client would use ETag headers on a GET to the feed as a way to ask the server for all of the changes since the last sync, but I'm not sure how well that would mix with paging. Regarding John's comment about about missing the tombstones--we have a mechanism for this in SSE. You can have an optional feed-level sx:sharing element with an "expires" attribute that gives the client guidance about how often to sync. Steven
