Paul Sandoz wrote:
> I did consider adding another field to the
> card<->ldap table which was an index. So
> 'SecondEmail' could be:
> xmozillasecondemail, 0
> mail, 1
>
> But it still does not solve the general
> problem for n > 2.
This is indeed a tricky problem, even though it can probably be considered
an edge cases. To make things even worse (at least on Address
Completions), what if a user has multiple CNs (assuming they don't use AD
of course :)?
As an example, it's not unusual for an IT organization to allow multiple
CN/mail combinations for people who have recently changed their names
(e.g. got married). So an entry might consist of
cn: Mary Lamb
cn: Mary Wolf
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
This is all legal and allowed as far as LDAP is concerned, and there are
no indications of which CN or Mail attribute is the "preferred". As you
know, most LDAP attributes are defined to be multi-valued, with only a few
exceptions. Heck, even UID is allowed to be multi-value, which can cause
all kind of weirdness in some applications today (i.e. someone making an
assumption that UID is single-valued).
I suspect that the right thing to do for now is to make every effort to
support multiple values, and try to avoid hardcoding assumptions that an
attribute is single-value (unless it's clearly defined as such). The
"default" value can probably be the one first returned by the
LDAP server (seems reasonable), but also make it possible in UIs that have
to handle this to support changing this interactively.
For instance, in an Address Completion session, we could generate four
lines of addresses to complete on when search for "mary lamb" (2 x 2).
This can become a very narly combinatorical problem, what if you have 8
multi-value attributes with 3 values each... :(.
Cheers!
-- Leif
