Re: Alias dereferencing

[Michael Reiher <reiher@vidsoft.de>]

On Saturday 10 September 2005 09:29, you wrote:
> Apparently, yes:
> <draft-ietf-ldapbis-models, section 2.6>
>       An alias entry shall have no subordinates, so that an alias entry
>       is always a leaf entry.
> </draft-ietf-ldapbis-models, section 2.6>
> p.
>

Hmm, too bad. Are there technical reasons for not supporting aliases which are 
no leaves? Actually that's something what I expect to work, from a users 
point of view. It's like filesystem symlinks that may only point to files, 
but not directories :) Anyway...

Now, if I'd want to implement this, i.e. to a) transparently handle aliases 
and b) support references to other backends. What would be the best way? My 
idea is basically to replace bdb_dn2entry() calls in e.g. search,add or 
delete operations, by a backend independent resolvedn() function. It would in 
the normal case simply call be_entry_get_rw(), and in case that fails, if 
neccessary, recursively resolve all aliases that occur within a dn or any dns 
derieved from it. That would involve entry lookups in the respective 
backends. Do you see any problems with that? For instance in bdb_add() the 
call to bdb_dn2entry() is with in a database transaction. I wonder if that 
would cause any trouble? Any advices would be greatly appreciated.

Greets Michael