Kurt D. Zeilenga wrote:
The rationale, I believe, for multiple consumer contextsI'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.
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.
-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support