[Date Prev][Date Next]
Re: When to delete client content during RFC4533 synchronization?
Erik van Oosten wrote:
There appears to be a detail missing from the RFC - when no changes
have occurred since the last refresh, for refreshOnly the provider
will send a Sync Done refreshDeletes control with no cookie. I.e., if
the state hasn't changed, the cookie would be identical, so there's no
need to send it back to the consumer.
You say Sync Done refreshDeletes, that is indeed what you get with
refreshOnly. However, with refreshAndPersist you get a single
syncInfoMessage of refresh*Present*. Shall I report this as a bug?
Please do, thanks.
My interpretation of 'no cookie' in the SyncDone/SyncInfoMessage was to
use no initial cookie in the next synchronization. But your
interpretation is probably better indeed.
For some reason I remember this being explicitly documented somewhere, but I
can't find a reference now. Maybe Kurt will remember, if he's watching...
For refreshAndPersist it always sends the cookie back. I think this
may be a bug, we probably shouldn't be sending the cookie in this case
either. So, you *should* be able to assume that no changes have
occurred at all when no cookie is returned.
Okay thanks, I'll use that assumption. I'll also use the assumption that
if the cookie is the same, no changes have occurred.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/