[Kolab-devel] No x-uid please. (was: Re: [NEW KEP] KEP #17: Kolab XML Format 3.0)

[Christian Mollekopf]

On 2012-03-13 14:48, Jeroen van Meeuwen (Kolab Systems) wrote:
> On 2012-03-13 13:22, Christian Mollekopf wrote:
>> On 2012-03-13 1:18, Jeroen van Meeuwen (Kolab Systems) wrote:
>>> If a Kolab client aware of the meaning of an x-uid attribute value
>>> reads a distribution list object edited by a client that has no
>>> understanding of the x-uid attribute value, the behaviour between
>>> the
>>> two clients is going to be different.
>>>
>>> Remember we've been there before and it wasn't pretty.
>>>
>>> Different clients showing different behaviour, precedence rules,
>>> conflict detection between asynchronous edits and conflict 
>>> resolving
>>> all kick in here, and for no good reason.
>>>
>>
>> No they don't, the behavior is very clear, there is no possibility
>> for
>> conflicts and we don't need precedence rules or conflict resolving.
>>
>> There is a mailto uri which serves the purpose of having an email
>> distribution list and is not directly connected to a contact. There
>> is
>> no need or desire to synchronize that to a Contact instance.
>> The x-uid property serves the additional purpose of being able to
>> link
>> a Contact object to that member, so it's easy to get to it. That is
>> an
>> additional usecase and there is no need to have the properties
>> synchronized in any way.
>>
>
> If the contact is referred to in a distribution list "Kolab Systems
> Employees", and the actual contact object has "Jeroen van Meeuwen 
> (Kolab
> Systems)" as the display name for one of its identities, and
> "vanmeeuwen at kolabsys.com" as the email address for that identity;
>
> - A client might update a distribution list to refer to the recipient
> address used in the distribution list as 'mailto:Jeroen
> <kanarip at kolabsys.com>' while the x-uid remains the same, causing
> de-synchronized state.
>

It is de-synchronized but neither inconsistent nor invalid. The x-uid 
remains valid (still referring to the right contact), and the mailto 
address has been changed to be correct in respect to the distribution 
list.

> - A client might update the actual contact object's display name (to
> "Jeroen van Meeuwen") or email address (to
> "jeroen.vanmeeuwen at kolabsys.com") corresponding with the identity, 
> while
> a mailto: value for the member element in a distribution list remains
> "mailto: Jeroen van Meeuwen (Kolab Systems) 
> <vanmeeuwen at kolabsys.com>",
> causing de-synchronized state.
>

Also this is not really an inconsitent (though de-synchronized) state 
as the mailto address in the distrbution list and the actual 
contact-object's email addresses don't need to be the same. It's very 
well possible that you have a contact object containing i.e. only the 
private email, but for a distribution list you want the company email 
address.

I'm not arguing that there is no usecase in wanting to have the same 
email address in member (mailto) and the contact. I just think we create 
more problems than we solve by making the assumption that we can rely on 
the contacts email addresses for the distribution list.


I can see now where you're coming from though. If you want to have the 
distlist email address strictly linked to one of the contacts email 
addresses the additional mailto uri adds redundancy, and the possibility 
to a de-synchronized state. Note that my concept of that property was 
different so far, as already lined out.

If we really want to go that route I'd rather reference by UID, and 
have the imap uri as an additional/optional reference. I already lined 
out some of the problems we will have to solve using that approach, and 
at least for contact we will also need to change the implementation 
accordingly. Also we would have to change the UI accordingly to reflect 
that behavior (as it is not what we currently have in KAddressBook).

So it's IMO a rather big effort.

On that note, the difference of the two concepts is nicely illustrated 
by KAddressBook groups and the ones in Roundcube. While you have a 
simple distlist, not linked to the contact in KAddressBook you have a 
group of Contacts in Roundcube.

I still think the x-uid version is a valid option with fewer 
requirements, we just have to figure out what we actually want from a 
distlist.

> - A client not aware of the x-uid attribute, nor what it's value 
> means,
> has *no* chance in either of the aforementioned cases to refer back 
> to
> the contact object.
>

Yes, obviously. It also has not if it can't make use of an imap url.  
With the imap url you're completely lost and have a disfunctional 
distlist, while with mailto you have at least the distlist covered.

Cheers,
Christian

> Kind regards,
>
> Jeroen van Meeuwen