[Kde-pim] [RFC] Contact specific Akonadi API

[Volker Krause]

On Friday 07 August 2009 18:03:29 Tobias Koenig wrote:
> So functionality from the old KAddressBook interface should be moved
> to a library as well and be usable by any other KDE application.
> The question is now:
>   What tasks are common enough to be worth putting them into the library?
>
> The tasks I came up for contacts are the following:
>
>   * tasks without gui involvement
>     - create a new contact in a predefined address book
>     - modify a contact with a given uid
>     - delete a contact with a given uid

where do you get that uid from?

>     - search a contact that matches a given pattern
>
>   * tasks with gui involvement
>     - create a new contact and allow the user to select the target address
> book - modify a contact with a given uid by show up a dialog, where the
> user can edit the contact - view a contact by show up a dialog
>
>   (same functions for contact groups as well)
>
> So my idea was to provide a job based API like in kdepimlibs/akonadi/ that,
> for the non-gui tasks, just wrapps the ItemXYZJob classes by converting the
> payload from/to KABC::Addressee objects internally. That doesn't add any
> real value but is a nice convenience layer IMHO. Depending on the ctor
> signature, the jobs could behave differently:

There is one problem with this approach though: If the Akonadi::Item object 
stays internal to these jobs, you will lose important information such as the 
UID and the revision for conflict detection, which are required when using 
the retrieved KABC objects later on for write operations again.

I don't think using Akonadi::Item in these jobs would be that inconvenient 
actually. Conversion to and from KABC objects is only one line if the jobs 
internally check if the payload type is correct already.

>   ContactCreateJob( const KABC::Addressee &contact, const
> Akonadi::Collection &collection );
>
> would add the contact directly to the given collection, while
>
>   ContactCreateJob( const KABC::Addressee &contact, QWidget *parent = 0 );
>
> would present a collection selection dialog to the user where he can select
> the collection himself.
>
> The job based API would allow easy usage in asynchronous and synchronous
> code by using start() or exec().
>
> What are your thoughts?

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090809/6c11e023/attachment.sig>
-------------- next part --------------
_______________________________________________
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/