List Info

Thread: Re: Feedback on Tombstones -04
Re: Feedback on Tombstones -04
user name
 2008-05-08 09:09:04 

  


  

    On Thu, May 8, 2008 at 8:28 AM, Mark Stahl < mstahlgoogle.com">mstahlgoogle.com> wrote:




On Wed, May 7, 2008 at 2:40 PM, James Holderness < j4_jameshotmail.com" target="_blank">j4_jameshotmail.com> 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.&nbsp; The at:deleted-since extension seems to me the simplest way to fill that need. 


 -- mark 


-- 
Test driving http://five.sentenc.es/

  

  
  
   
     
    

  

    Re: Feedback on Tombstones -04
  


  

     country flaguser name
United States		
     2008-05-08 09:35:17
  


  

    
Mark Stahl wrote:
> On Thu, May 8, 2008 at 8:28 AM, Mark Stahl
<mstahlgoogle.com> 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

 




  


  

    
  

  
  
   
     
    






 [1-2]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )