[Kde-pim] KABC Contact Groups

[Christian Mollekopf]

On Wednesday 15 May 2013 17.32:26 Kevin Krammer wrote:
> On Wednesday, 2013-05-15, Christian Mollekopf wrote:
> 
> > 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
> 
> Contact group currently uses a vendor specific MIME type. If a newer version
> of vcard can now handle that directly then we could probably switch to
> items of that type and maybe provide some import/conversion/cleanup tool?

Moving to vcard would be a good idea IMO, yes.
We could provide a conversion tool, but I'm not sure how that would work. Is 
that any special way how this should normally be handled?

Of course it would also be possible to convert gradually by still being able 
to read the old format but serialize it in the new format.

To summarize:

== Problems ==
Kolabproxy doesn't work with group references:
1. contacts are moved to a new item when modified externally, which breaks 
contact references (because they are based on the akonadi itemId)
2. There is no akonadi itemId outside of akonadi, so the itemId needs to be 
resolved to a uid

== Solutions  ==

=== 1.1 Don't move contacts on external edit ===
* Requires tracking the UID, and finding the appropriate item again.
** Either have a UID-itemId map of all items
*** Doesn't scale memory wise
** Search through all items
*** Doesn't scale performance wise

While not fast, edits are also not that frequent, so I guess it should be 
doable. Being able to search by UID would fix the performance issues.

=== 1.2 Don't fix ===
=> KABC needs to be fixed

=== 2.1 Wait for all contacts to arrive until group is resolved ===
Because it can happen that not all contacts which are being reference are on 
the system, the group can only be created once the contacts are synced (so the 
itemId is available).

This too, like 1.1, requires searching through UID's (with it's performance 
penalties)

Not pretty but would work (more or less)

=== 2.2 Don't fix ===
=> KABC needs to be fixed

== KABC fix ==
Fixing KABC means not relying on itemId's for references and using UID's 
instead.

=== Fix for 4.x ===
This requires backwards compatiblity and no BIC changes.

* keep format
* store UID in an extra field
* when loading a contact, retrieve UID if not available and only akonadi 
itemId is available (for backwards compatibility)
* add fallback code, where the itemId is used, to search the contact based on 
UID

Here we require search through UID's in the KABC code, so it's performance 
wise potentially worse than doing it on the resource side. However, I think 
it's the right place for the fix.

=== Fix for 5.x ===

* replace custom format with vcard based fromat
* drop akonadi itemId entierly for references, and use UID only

Also requires searching through UID's.



Because I think fixing KABC is the right way to go, I'm pursuing "Fix for 4.x" 
right now. But let me know if you think otherwise.

I think fixing KABC is the right way because:
* Akonadi itemId's are an implementation detail and should never appear in a 
payload.
* KABC maps better onto vcard
* Resources are not cluttered with code for resolving id's to UID's which they 
shouldn't have to do (IMO)

As you may have noticed, we have to search through the UID's in one place or 
another ;-) As this is very inefficient currently I think we should support this 
in the db. I'll send a separate mail regarding this.

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/