[Kde-pim] Akonadi being a desktop-indepent standard

Tue Aug 19 09:03:37 BST 2008

On Monday 18 August 2008 14:45:00 Kevin Krammer wrote:
> On Monday 18 August 2008, Holger Berndt wrote:
> > David Jarvie schrieb:
> > > Akonadi provides data access and caching, not data storage. So there is
> > > no question of outsourcing actual mail message storage - you can
> > > continue to store data in the format you currently use.
> >
> > Thanks for explaining that to me.
> >
> > > To access a data store,
> > > Akonadi uses a 'resource' which knows about the particular storage
> > > format and how to access it. If you want to store your email data in
> > > mbox format, for example, an Akonadi mbox resource will be required. If
> > > no resource currently exists for a storage type, the ResourceBase class
> > > in the Akonadi library provides the basis for writing a new resource to
> > > access it.
>
> While Akonadi server is not a storage itself as David explained, from a
> client application's point of view it acts as a storage.
>
> An application could still use its own storage for some data, e.g. in your
> case email, and Akonadi for others, e.g. contacts.
>
> However, ideally access to data would not depend on specific applications
> since it results in export/import task when changing between them.
>
> > Unfortunately, that doesn't help in the problem domain that I had in
> > mind.
> >
> > As I said before, my interest is more for independant, stand-alone PIM
> > components to speak a common language in order to interact during common
> > PIM tasks. Let me give a few more examples:
> >
> > What a MUA could request:
> > - dear addressbook, whoever you might be, please add the following
> > contact: John Doe <john.doe at tld.org>
> > - dear addressbook, please give me a list of all contacts
> > - dear addressbook, please open up contact xy for editing. Or just show
> > me your main window.
> > - dear calendar, whoever you might be, I just received a meeting
> > invitation via email. Please insert that event into my calendar
>
> IMHO this mixes two problem domains.
>
> Domain one is about accessing data, examples 1, 2 and 4
> Domain two is about delegating data manipulation, example 3 above.
>
> Akonadi is about solving domain one, centralized access to shared data.
>
> Domain two could probably be solved by using a "preferred application
> launcher" approach, e.g. like launching the preferred application for a
> certain URI and MIME type, though this would need some extenting to allow
> the caller to be notified once the operatation is completed.
>
> > Similarly, the addressbook could ask the MUA to open up a new message to
> > contact xy. Or the calendar could ask the MUA to send out invitations to
> > a newly created event. The addressbook could ask the calendar to add
> > birthday entries for all contacts.
> >
> > A sync engine could ask the notes program, the calendar, the mailer, and
> > the addressbook to get/add/delete/modify entries. Etc. pp.
>
> Hmm, right, there should probably be an interface/spec for
> composing/sending mail.
>
> The other two examples are again more about actually accessing shared data.
>
> > Signal/slot connections are also imaginable. The mailer says: Hey,
> > whoever might care: I just received a mail!
>
> True, in an Akonadi setup this already happens, like for any other change
> on data items.
>
> > All those tasks don't require a lot of data being shoveled accross
> > applications.
>
> Not entirely true. One of your examples above is "list all contacts" which,
> assuming you want the actual contact contents, could be quite some data.
>
> > Having a central daemon for data access isn't needed there, and is IMO
> > even counter-productive. What would be needed for that was really just
> > an interface definition which interested applications could implement.
>
> Definitely for problem domain two, though I am not so sure about domain one
> due to potentially requiring quite some data transferring.
>
> > Therefore, I understand that this is not the core problem domain that
> > Akonadi wants to address. If, on the other hand, Akonadi would also
> > implement such an interface, all applications relying on Akonadi would
> > be accessible from outside. Are you guys interested in that kind of
> > interoperability?
>
> I think that KDE PIM in general would certainly be interested in the
> problem domain two type of interaction and if others are interested in
> home-user level data size or D-Bus base iterator style access we could
> certainly implement this as a special form of Akonadi client, though it
> might be more efficient to access the data directly using a direct
> connection to the Akonadi server.
>
> Till or Volker can probably give you an estimate on how much work such a
> direct connection would be if one can start with the facilities of a fully
> featured mail client (Akonadi's protocol being similar to IMAP in some/most
> aspects)

It's of course possible to build such an interface on top of Akonadi. Probably 
wouldn't take too much time even, Akonadi provides this functionality more or 
less already. However I see two issues with this approach, issues we have 
with our current KResource based infrastructure in KDE PIM and which were 
crucial in the decision to build Akonadi:

- Synchronous API. Easy to use and works nicely for 100 contacts in a local 
vcard file, but fails completely for 10k+ entries on a LDAP server with a 
poor network connections. Therefore most methods in the Akonadi client API 
are asynchronous. That's much less pleasant to use of course, but in our 
opinion the only way to deal with the amounts of data we have here.

- Data access via applications. In KDE PIM we used that for the Kolab backend 
which uses KMail to access the server. So, every application accessing 
contacts would launch KMail, which was extremely confusing for users. 
Therefore we use a dedicated server for Akonadi.

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