[Kde-pim] KABC Contact Groups

[Christian Mollekopf]

On Wednesday 15 May 2013 16.19:45 Kevin Krammer wrote:
> On Wednesday, 2013-05-15, Christian Mollekopf wrote:
> > On Wednesday 15 May 2013 12.42:45 Christian Mollekopf wrote:
> > > Hey,
> > > 
> > > KABC::ContactGroup uses the akonadi item id of a contact as uid, which
> > > is
> > > IMO a bad design decision, because contact groups are synchronized to
> > > other systems where the id's are obviously not valid any more.
> >  
> >  also, if the kolab proxy syncs an updated contact, it removes the old
> >  item
> > 
> > and creates a new one, which breaks the link for obvious reasons.
> > That's arguably a shortcoming of the kolabproxy, but I think nevertheless
> > that references should refer to the underlying logical contact object (by
> > it's uid), and not to the container (the akonadi item).
> 
> Lets take a look at the goals and the assumptions that lead to the current
> implementation.
> 
> One goal was to have the option of linking contacts into groups such that
> changing any contacts details would automatically be reflected by the group.
> Assumption of course being that all contacts have an item id and that this
> id is always unique, even in the worst case of the same vcard being used by
> two resources.
> 
> In a way such distribution lists are a bit like virtual collections with
> contacts linked into them but actually being items instead.
> One reasons is that they can also contain a "detached" contact info,
> something not linked to an actual contact.
> 
> From the Kolab point of view, can you give an example on how you store
> contact groups?

We store contact groups in the vcard format (more specifically xcard which is 
the xml version of the vcard rfc6350). That is a vcard with the "kind" 
"group", containing a list of member.

> How do you deal with a contact not being in any contact folder of the user
> saving/loading the contact group?
> 
We don't. The group either contains name/email pairs, or references. 
References consist solely of a UID, where the UID is an actual globally unique 
identifier, just as it's used i.e. in ical, and as mandated by the rfc.

Of course the references are hardly useful if the corresponding contact is not 
available, which is ok i.e. in a scenario where users don't have access to all 
contacts due to shared folder etc. In such a case the reference remains simply 
unresolved, but doesn't result in dataloss as the client can still preserve 
the (dysfunctional) reference as it's just a uid.
Note how a reference also always remains valid, as it is theoretically 
guaranteed that no second contact will ever exist with the same uid.

Apart from those general advantages, there is also one problem I can't easily 
work around. Even if the user would have access to all contacts referenced in 
the group, it is entierly possible that the group is synced to the system 
before the contacts are, but KABC requires me to have all contacts already 
created in the local akonadi instance to be able to create the references in 
the group.

So I have the following problems with the current implementation of groups:
* Very hard/expensive to cater to it's requirements when synchronizing and 
groups don't come in a single block together with the contacts
* The implementation holds the assumption that a contact always remains in the 
same akonadi item (which is not the case for kolab).
* The format is IMO only suitable as internal storage format (which it also 
is), as it relies on implementation details (the item id's), the problem is 
that those details also leak through it's interface (the uid isn't a uid), 
which makes it basically a locked in format (that's possibly why the vcard 
serializer doesn't support groups).

My preferred path forward would be:
* adjust kabc that it's compatible with vcard (use uid's and not item id's as 
references)
* adjust all kde code to work accordingly
* keep compatibility for existing uses which rely on the uid being an akonadi 
item id. That won't work with i.e. kolab, but it never has either.
* Drop all uses of the akonadi item id in the interface, and replace the 
storage format by vcard in KDE5

Cheers,
Christian
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/