[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncrepl simplification
The rationale, I believe, for multiple consumer contexts
within a database context was that administrators could state
different consumer policies for different areas of the DIT.
At 08:22 PM 1/11/2005, Howard Chu wrote:
>There seems to still be a lot of unnecessary complexity in the syncrepl implementation. I'm rather skeptical of the value of having multiple consumer contexts within a single database. A single database like this cannot be used in a cascade to provide for other consumers, because there can only be one provider context and there is no assurance that the CSNs of the multiple consumers will be in any way coherent. As such, it makes the most sense to keep only one consumer context per database/naming context.
>
>If we restrict the implementation to using only one consumer per context, then we can collapse the consumer contextCSN into the suffix entry, the same as was done with the provider context. Then we don't need to mess around with the slapadd options for promotion/demotion of provider/consumer since the same contextCSN info is used in all cases. This would allow us to remove the -p, -r, -w, and -i options from slapadd, and save a lot of administrative overhead re: promotion/demotion. (Actually I would keep the "-w" option to write the contextCSN. Saves time for the provider, and allows the resulting database to be slapcat'd and immediately slapadd'd into any consumers without any more fuss.)
>
>Comments? I guess I'm looking for a compelling example of the usefulness of multiple consumers in a single database. I suspect any example can be accomodated using separate databases and the glue overlay, and the glue approach probably provides more efficient security/isolation anyway.
>
>--
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support