RE: aliases

["Pierangelo Masarati" <ando@sys-net.it>]

> Howard Chu writes:
>>> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
>>>
>>> I guess dereferencing aliases in another database is out of the
>>> question?
>>
>> Beyond present consideration, yes. It would be possible to push alias
>> processing into the frontend, but it would add a lot of overhead; the
>> frontend would need to keep a list of all DNs processed so that it
>> could prune duplicates and cycles. This would use up a lot more memory
>> than just the candidate ID lists that are currently used in the
>> backend.
>
> I think that can be avoided, but it feels pretty hairy so I expect that
> is even farther beyond present consideration:
>
> The backend processes all the aliases it can, and then returns to the
> frontend the search results, the aliases to outside its database, and
> the data structure it used to prune duplicates and cycles.  If the alias
> dereferencing ends up calling the same backend again, the frontend
> passes the backend's data structure back to it, so the backend can keep
> pruning cycles and duplicates.  After the search is completed, the data
> structure is passed to the backend again so it can be freed.

(Slightly OT)

We need a solution of this sort if we glue together etherogeneous
backends in the way back-meta does.  In fact, a (poorly configured)
back-meta may well return duplicate DNs; while in some cases this
is pathological, in others it may be beneficial, so, a rule to prune
already processed entries, or, in other cases, to merge entries
based on the DN, could be interesting.
In this case, of course, entry sending should be delayed until
all entries are collected, which would be a nightmare for hardware
resources unless large searches are carefully limited.

We are again talking about sophisticated means of making
front/back-ends dialog.

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it