Re: syncrepl ramblings again

["Jong-Hyuk" <jongchoi@OpenLDAP.org>]

>This might be a nice project for someone: turn syncrepl provider support
> into an overlay.
>     Right now the code and data necessary to support it are scattered
> across a lot of files, and tiny changes (like be_context_csn) are hard
> to keep coordinated, easy to get lost.
>     At least Persistent Search should be provided as an overlay, and it
> would be useful across many other backend types.

I agree that the overlay will be a good way of implementing the syncrepl
provider functionality.
At the time of initial syncrepl design, the overlay was only at its initial
stage, but it's quite mature now.
Also I like to reorganize syncrepl using overlays for multiple backend
support and to minimize
interferences with other modules with a well defined interface.

>     In back-bdb we really don't need the last committed CSN to be stored
> in a real database entry, we could just search for the greatest CSN at
> startup time. We could store it at shutdown time, but for the most part
> it would be better as a memory-only virtual entry.
>     The actual search operations that are associated with the syncrepl
> control aren't "special", they can be performed using a regular search
> with an appropriately constructed filter. At least, it appears to me
> that they are not intimately tied to the workings of the database.

Agree. This can be done at the request / response paths with the overlay
mechanism.

> Overall I would like to see some more consolidation of this code, and
> all references to CSNs encapsulated into a component (i.e. an overlay)
> that is optional instead of hardcoded as it is now. This isolation would
> help reduce the chance of breakage that is rampant right now whenever
> some other sturcture definition changes...