On Thu, May 8, 2008 at 8:28 AM, Mark Stahl <[EMAIL PROTECTED]> wrote:
> > > On Wed, May 7, 2008 at 2:40 PM, James Holderness <[EMAIL PROTECTED]> > wrote: > > > > > Mark Stahl wrote: > > > > > This leads to problems with clients that periodically poll for > > > changes - they don't know if the set of tombstones is complete > > > since the last time they polled. > > > > > > I'd suggest adding an element at:deleted-since, so the server > > > can let the client know the tomebstone window in effect. > > > > > Assuming you did know whether the set of tombstones was complete or > > not, how would this effect your behaviour as a client? In other words, what > > would you do differently if you knew the set of tombstones was incomplete? > > > > James, > > 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. -- mark -- Test driving http://five.sentenc.es/
