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

[Kevin Krammer]

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)

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- 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/20080818/e077451f/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/