[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: syncrepl simplification

Kurt D. Zeilenga wrote:

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.

I'll have to think about that some more. To me, it still sounds like a recipe for disaster. If the separate consumer contexts are talking to different providers, then you have the cascade problem I mentioned before. If the contexts are all pulling from the same provider, then I guess it works. I still don't see any rationale for the updatedn on the consumer; surely any data that the provider returns must satisfy the consumer criteria and therefore must be reflected into the consumer DB.

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.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support