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

[Holger Berndt]

On Wed, 20 Aug 2008 09:14:35 +0200
Kevin Krammer <kevin.krammer at gmx.at> wrote:

> However, ideally access to data would not depend on specific
> applications since it results in export/import task when changing
> between them.  

I can see the usefulness of this approach, however, that's not really
an option for Claws Mail. While being great for newly created clients,
I doubt many older ones (except KMail, of course) will want to depend
on Akonadi for data storage soon. That's too much of a core competence.
I see potential for cooperation elsewhere.

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

These surely are two different layers, yes.

> Akonadi is about solving domain one, centralized access to shared
> data.  

Understood. This is not really a problem though. One would just have to
take care to split data manipulation services from UI services, so
maybe say have a
 org.freedesktop.pim.addressbook.datastorage 
and a
 org.freedesktop.pim.addressbook.ui
service. In the case of KDE, the former could be implemented by Akonadi,
and the latter by Kontact. In the case of GNOME, the former by EDS, the
later by Evolution. Claws Mail would handle both.

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

I woudln't base it on an URI or MIME type, but on those services
defined above. The user would select which application/daemon was to
provide the org.freedesktop.pim.addressbook.datastorage service, which
to provide the org.freedesktop.pim.calendar.datastorage service etc.
D-Bus already has the infrastructure for that using .service files.

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

That is true for e.g. company-wide addressbooks, or shared calendars.
That's not really a show-stopper, though. Possible solutions would be
to put limits in the API (give me the next 100 contacts, and tell me
whether we're done already), or access local storage only. Frankly, when
I want to sync my cell phone, I am not synching against the 300.000
entries company LDAP server.

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

That's good news. I am not saying KMail has to talk to Akonadi using
such a spec. Specialized access can always be more efficient than
a general spec. The whole point of me starting this thread, however, is
to have a common language that does explicitely NOT rely on the
application itself.

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