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
