On Saturday 10 September 2005 09:29, you wrote:Well, one good technical reason is that only the Search operation provides a Deref option. Put another way, the Search operation is the only one intended to recognize aliases. And it's the only one that gives clients control over whether to dereference them or not.
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?The best thing to do would be to take a step back and think about something else for a while. Then read through the LDAP specs and gain an understanding of what facilities are already provided, and how to use them to your advantage. Some things to think about - why does your design require the use of aliases at all, why don't your applications already know the real DNs of the entries they need to operate on? Why does your design require the use of multiple backends?
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/