Mark Stahl wrote:
On Thu, May 8, 2008 at 8:28 AM, Mark Stahl <[EMAIL PROTECTED]> wrote:
The issue is sync, and the diffrence is between incremental and full
sync.
Assume a client has previously downloaded a complete copy of a collection
at time T1. Some time later, T2, the client retrieves the updated feed.
Assume entries and tombstones are both in app:edited order, as suggested
by
Mark Nottingham. If the client knows that the server is still holding
tombstones of all entries deleted since T1, then it can correctly update
it's local copy of the collection to be in sync with the server.
Otherwise,
it must retrieve the full collection and manually calculate the missing
deletes in order to sync.
But just to reiterate my reasons for suggesting this, it's *not* my goal
to
write a sync algorithm into the at:delete-entries spec.
I'm just suggesting that we should provide a way for a service to indicate
there may be deleted entries it has forgotten about. The at:deleted-since
extension seems to me the simplest way to fill that need.
I don't have any objection to the at:deleted-since idea, but it seems
impossible to describe in a useful way without describing part of a
synchronization protocol.
Besides expiration, there is another reason that a feed may not contain
tombstones for all deleted entries. If any information is encoded in that
atom:id (e.g. the title of the entry), then the feed producer may provide a
mechanism for a user to delete an entry without producing a tombstone, to
prevent information leaking via the atom:id. So, even if you sync within the
time frame suggested by the at:deleted-since element, you might not get all
of the tombstones.
- Brian
