It's becoming untenable how a plain refresh cannot be represented in accesslog in a way that's capable of serving a deltasync session. Whatever happens, we have lost a fair amount of information to run a proper deltasync yet if we don't want to abandon this functionality, we have to try and fill some in.
The current issues: With refreshDeletes=FALSE we get a list of entries in no particular order (each can be tagged with a CSN of the latest change), then have to synthesize a list of deletes with no idea what CSN they belong to at all, the best we can do is pick the whole CSN vector (we certainly *cannot* pick a single CSN for any of them, not even the highest timestamp). If we're receiving refreshDeletes=TRUE, we have lost less information as there are no implied deletes in the normal case where no subtree renames happen to remove a whole subtree from view (we fail here at the moment). Updates are still liable to be returned in arbitrary order, at least we know they're tagged with some sort of CSN, most likely the CSN of the last change to the entry except for entries that have been deleted. Some of the above is due to how the provider decides to send information down to us and we are free to change that. The major gap that the provider cannot fill is deletes implied by present phase ending. The entries deleted there cannot be tagged with a single CSN since we need to remember the whole vector to make a consistent decision whether or not to recreate an entry in the future. Since we do not follow RFC 4533 in many aspects already, e.g. we send cookies in the middle of a refresh, our cookies are often unusable on their own, we can just own up to this and define an extension to the protocol if needed. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
