[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: syncrepl ramblings again

At 02:55 PM 9/1/2004, Howard Chu wrote:
>Kurt D. Zeilenga wrote:
>
>>>What was the motivation for not keeping tombstones around?
>>>   
>>
>>Tombstones, in general, don't hold enough information for
>>the provider to determine whether or not a delete message
>>has been sent to a prticular client, resulting in need to
>>send extra deletes messages.  Sessionlogs, on the other
>>hand, track exactly which deletes a client needs to see.  
>>
>>Note that the question the provider has to answer is
>>subtlely different than "what entries were deleted since
>>the client last sync'ed?" but "what delete messages does
>>the client need in order to sync?".  Sessionlogs are better
>>at answering that question.
>> 
>I'm not disputing the value of the sessionlog. But if a tombstone carries entryDN, entryUUID, and entryCSN, then it would seem pretty unambiguous to me.

How does the server know whether the entry was or wasn't included
in the content at the time client previously synced from this?
The entry could have been updated (modified, renamed, deleted)
numerous times since the last sync.  The server, not knowing
whether the entry was in content, MUST assume that it was.  This
means that for each and every entry IN THE CONTEXT (not just the
subtree) updated since the last sync, the server MUST send a
message to the client (a "update" message if still in the content,
otherwise a "delete" message).  That is, the delete+update
refresh would be N+M messages where N+M was equal to the
total number of entries updated in the context.  Additional
history information would be required to determine whether
any of the N deletes were unneeded.

>The client just says "send me everything >= my-last-CSN" and everything should be fine. No?
>-- 
> -- Howard Chu
> Chief Architect, Symas Corp.       Director, Highland Sun
> http://www.symas.com               http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support