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

Re: syncrepl and aliases

At 01:54 AM 11/4/2004, Howard Chu wrote:
>Kurt D. Zeilenga wrote:
>>At 01:52 AM 10/30/2004, Howard Chu wrote:
>>>I'm still working on rewriting the syncprovider as an overlay. Separating the code out of back-bdb/search.c is proving to be difficult. Just as a matter of principle, should the search scope for a syncrepl search dereference aliases?
>>
>>3.5.2.  derefAliases
>> 
>> This operation does not support alias dereferencing during searching.
>> The client SHALL specify neverDerefAliases or derefFindingBaseObj for
>> the SearchRequest derefAliases parameter.  The server SHALL treat
>> other values (e.g., derefInSearching, derefAlways) as protocol errors.
>> 
>>
>>>I would guess that a consumer trying to replicate a particular subtree doesn't care about entries outside of that subtree. So entries that only enter the scope by virtue of a deref shouldn't really be considered. If that's the case, evaluating which entries to return can be simplified a fair amount.
>>>   
>Thinking about this some more, I see problems with derefFindingBaseObj as well. Again, if a consumer expects to see entries under a specific subtree, and the base object is aliased to a different subtree, the DNs of any returned entries will be "wrong."

If the client is designed not to expect aliasing, then it
should specify neverDerefAliases.  In some applications,
the value of the DN really doesn't matter.  For these
applications, clients can use derefFindingBaseObj.

Kurt