[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:       Kevin Krammer <kevin.krammer () gmx ! at>
Date:       2008-08-20 17:22:40
Message-ID: 200808201922.48601.kevin.krammer () gmx ! at
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 20 August 2008, Holger Berndt wrote:
> On Wed, 20 Aug 2008 09:14:35 +0200
>
> Kevin Krammer <kevin.krammer@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.

This is why I wrote that applications such as Claws might just want to use 
Akonadi just for "foreign" data, in your case e.g. contacts.
We understand that any kinf of migration of an application's core data will be 
quite some effort, we do have the same work ahead for KDE's PIM applications.

I slightly disagree that mail storage would be a core competence of a MUA 
unless it has very tight coupling between its features and the way the data 
is actually stored on disk.

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

Sounds reasonable.

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

.service files are not good enought for this kind of scenario since they 
basically are very static configuration.
When discussing the issue of user configurable service choice with the D-Bus 
folks we ended up with an idea to use a specially priviledged service to 
configure the activation during runtime, though nobody has started any work 
on implementing it.

It is also a bit more complex on the application's side since they need to 
know when to register the respective bus name, otherwise manually launching 
an application which is not the preferred one will have all calls routed to 
itself instead of getting the preferred one autostarted.

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

I guess as long as developers using the interface are aware of its inherent 
limitations that might be good enough.
Though at least in the case of an Akonadi based setup using a direct 
connection will get better results and might be preferable for applications 
which operate on the data as their main target, e.g. mail for MUAs.

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

Well, for the data access and management problem domain this is also one of 
the reasons for Akonadi's design, e.g. access to contact data from a MUA does 
not depend on any specific implementation of an addressbook application, 
storage location or method of access to such locations.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]

_______________________________________________
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]