[Kde-pim] RFC: ContactGroup2: UID based references

Christian Mollekopf chrigi_1 at fastmail.fm
Wed May 29 13:12:28 BST 2013


On Wednesday 22 May 2013 17.36:45 Christian Mollekopf wrote:
> Hey,
> 
> In the light of:
> http://git.reviewboard.kde.org/r/110591/
> http://git.reviewboard.kde.org/r/110592/
> 
> I'd like some feedback if you think this is going in the right direction.
> Porting everything to ContactGroup2 will be quite a task, involving a
> ContactGroup2 version of everything exported in kdepimlibs and porting all
> applications using it (in particular the akonadi resources and
> KAddressBook), so I'd rather make sure this is leading somewhere ;-)
> 
> == Reasoning ==
> I think ContactGroup is flawed because it uses the akonadi item id as
> reference, which results in issues when synchronizing. In particular:
> * The akonadi item id is an implementation detail, and is not valid outside
> of akonadi. Hence it is basically invalid even if you store the group to a
> vcard. * VCard 4 support groups (wasn't supported before), allowing us to
> store groups in a standard format (currently we're using a custom xml
> format) * While resolving the akonadi item id to UID when serializing is
> generally possible, it's IMO the wrong place for such a thing to happen,
> and it's not necessarily possible when deserializing. If the contact with
> the referenced uid has not yet been synchronized (and hence the akonadi
> item id is not available), it is not possible to create the contact group
> until all referenced contacts are synchronized, which is an unnecessary
> restriction.
> 
> IMO the only sustainable path forward is having ContactGroup references
> using UID's, which is also what vCard 4.0 supports.
> 
> Note that an alternative approach to ContactGroup2 would be to extend
> KABC::Addressee with with a type (Individual, Group) and a list of members.
> That way KABC:Addressee would just represent a vcard, which would result in
> less code, but give away the typesafe distinction between groups and
> contacts. I therefore prefer the ContactGroup2 solution.
> 
> == Migration ==
> I plan to either add migration code, which would migrate all ContactGroups
> to ContactGroup2 during akonadi startup (similar to the creation of default
> collections), or to rely on gradual migration using a compatibility
> serializer which converts ContactGroup objects on the fly to ContactGroup2.
> 
> 
> I'd appreciate an ACK/NACK before going forward.

I'll consider this a silent agreement ;-)

_______________________________________________
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/



More information about the kde-pim mailing list