On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote: > 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.
Had a discussion on how to address this, some proposals have been floated so far, I'll broadly keep them to one per thread. This is one of them, call it proposal 1 if you will. Changes are contained to the provider: During a refresh (both present and delete phase), we send entries and deletes ordered by CSN, this makes their consumer's accesslog in better shape for deltasync consumption. Currently we send deletes first, then updates if we run a delete phase. This requires that we change that[0], mixing output from sessionlog and internal search, which for accesslog based sessionlog calls for two concurrent searches being run while processing a single operation, that's currently impossible. And we need to provide an efficient server side sorting implementation that does this without reading all entries first, then sorting them. This way we never explicitly send changes out of order. Except that there remains an implicit out of order change at the end of a present phase, the consumer still has to log those implied deletes somehow and choosing any single CSN leads to scenarios where divergence is still inevitable. On the other hand, any part of this change can be introduced at the same time as most of the other proposals. [0]. RFC 4533 is extremely vague about when updates are sent at all during refresh, so it seems we are within our rights to do this. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
