[Date Prev][Date Next]
Re: syncrepl ramblings again
- To: Howard Chu <firstname.lastname@example.org>
- Subject: Re: syncrepl ramblings again
- From: Pierangelo Masarati <email@example.com>
- Date: Sun, 26 Sep 2004 23:58:01 +0200
- Cc: openldap-devel@OpenLDAP.org
- References: <413107F2.firstname.lastname@example.org>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Howard Chu wrote:
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.
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.
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...
Did anybody take any steps in this direction yet? I'm about to need
syncrepl producer features on arbitrary backends... and I'm considering
the opportunity to add csn and uuid to back-sql.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497