[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Akonadi being a desktop-indepent standard
From:       Holger Berndt <berndth () gmx ! de>
Date:       2008-08-18 12:11:50
Message-ID: 48A96706.7040205 () gmx ! de
[Download RAW message or body]

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.

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@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

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.

Signal/slot connections are also imaginable. The mailer says: Hey, 
whoever might care: I just received a mail!

All those tasks don't require a lot of data being shoveled accross 
applications.

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.

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?

Holger
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]