Erik van Oosten wrote:
> There appears to be a detail missing from the RFC - when no
> 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
> 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
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/