>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... :(.
>
Thanks for the clarifications.
I think that a 'proper' solution is to rewrite
the nsIAbCard interface and the implementations of
such that the nsIAbCard inherits from a property
bag interface (or a multiset in stl argot) which
supports properties with name space rules so that
it can contain the likes of:
mail: a@a
mail: b@b
mail.internet: c@c
mail.work: d@d
(in much the same way as branches in preferences)
A request for property 'mail' could return an
enumeration or array of all 'mail' and 'mail.*'
properties.
This could then support most (i think..) of the vCard
schema with ease.
The explict attributes on the nsIAbCard could be
removed and it also means that by default new properties
may be added to the bag or multiset, which means that
the anonymous attribute support in nsIAbMDBCard is
no longer required and they become first class property
citizens! which makes the AIM in netscape 6.x independent
of the MDB implementation.
I guess that we need [gs]etString [gs]etInt, [gs]etBool,
[gs]etBinary so that stuff like images etc can be efficiently
supported cause of no XPCOM Any support :-(
(i logged: http://bugzilla.mozilla.org/show_bug.cgi?id=77530)
The RDF card datasource can still use the same
property names, which are mapped to the vCard syntax,
so that no GUI changes are required, but could be
modified at a later date to take full advantage
of the vCard properties.
Thanks,
Paul.
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219
