[Date Prev][Date Next]
Re: syncrepl simplification
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
Symas: Premier OpenSource Development and Support