>> I like the idea of relating ldap attributes to
>> ldap attributes and fixing the relationship between
>> Mozilla card properties and ldap attributes.
>
>This seems like a good idea. But isn't it orthogonal to the above
>question of how we connect it to the preferences? I'd be interested
>in hearing if any of the prefs & prefs locking folks have any opinions
>on this...
>
Yes.
Hmm... i think i was trying to suggest that
its probably better not to reference the
mozilla card property names in the preferences.
>> >> /*
>> >> Table defining the relationship between
>> >> mozilla card properties and corresponding
>> >> ldap properties.
>> >>
>> >> Multiple entries for a mozilla property define
>> >> there is a many to one relationship between
>> >> ldap properties and the mozilla counterpart.
>> >>
>> >> There is a one to one relationship between
>> >> a mozilla property and the ldap counterpart.
>> >> If there are multiple entries for a mozilla
>> >> property the first takes precedence.
>> >
>> >What if there are multiple entries for an LDAP property? I don't
>> >_think_ LDAP guarantees that they will be returned in a predictable
>> >order, though I could be wrong.
>> >
>>
>> Currently there is no provision for managing multiple
>> entries, the first one wins. I was not sure how to
>> deal multiple entries...
>
>I just asked Leif about this, and he said that the protocol does not
>guarantee a predictable order, though the current versions of the
>Netscape/iPlanet directory server happen to return them in the same
>order every time. I'm not real sure what could be done about this
>either, other than making the address book code support multi-valued
>properties like LDAP does. I'm not also sure what the UI and code
>implications of this are (ie whether it's really practical). But it
>would probably solve Gerv's multiple email address problem.
>
It would solve multiple email in some way
but which email address takes priority if
order cannnot be guranteed?
Does it matter?
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.
Unless of course another card is created
instead but that is not the point :-)
Paul.
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219
