Michael Reiher wrote:
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...
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.
Now, if I'd want to implement this, i.e. to a) transparently handle aliases
It would be a mistake to implement (a) since you'll have no way to
specify when you want to Modify the alias entry itself, vs what the
alias points to.
and b) support references to other backends.
It would be a mistake to implement (b); that is already the purpose of
referrals.
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?
Something else to think about - you should not be thinking about how to
"fix" code that isn't broken, this shows a lack of understanding of the
existing code. Trying to write new code before you understand the
existing design and implementation is ... obviously a bad idea.
--
-- 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/
