[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slurpd and back-config
I note that one aspect of slurpd architecture is that one can
insert a replog rewriting agent between slapd(8) and slurpd(8).
If we move all the provider side into an overlay, we'd lose
this.
Maybe it is better to simply say that slurpd users cannot
use back-config?
Kurt
At 06:08 PM 5/20/2005, Howard Chu wrote:
>It doesn't seem worthwhile to pull in all the changes needed to bring slurpd up to date here. I'm more inclined to implement slurpd-like functionality in slapd, and delete slurpd.
>
>First we could move the existing replog functionality into an overlay, as I've suggested before. Next the overlay itself could submit update tasks (using the thread pool or the runqueue, as appropriate) to update remote servers. It could use libldap_r directly, or it could operate through back-ldap/back-meta. I'm somewhat favoring the back-ldap/back-meta approach, as it opens the possibility to use the rewrite overlay in the replication process.
>
>The one thing we'd lack is a standalone/one-shot mode, but we could create a slaptool for that purpose. E.g., define a SLAP_BFLAG for "one-shot" mode; whenever the tool runs it will invoke all the backends/whatever that have this flag defined and skip anything that doesn't have it defined.
>
>--
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support