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
