[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-16 13:08:29
Message-ID: 200808161508.36965.kevin.krammer () gmx ! at
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Holger,

On Saturday 16 August 2008, Holger Berndt wrote:
> Hello PIM people,
>
> I am a supporter of the desktop independant, GTK+ based mail user agent
> Claws Mail. Its (few) developers are pretty evenly split between
> between being KDE, GNOME, and XFCE users.

I haven't used it myself yet, but IIRC one of my friends is a big fan of its 
Maemo port.

> I've thought many times that it would be great to have a
> freedesktop.org standard for PIM component access and interaction.
> Ideally, this would allow for all PIM components implementing this spec
> to be interchangable with out loosing integration, so the user could
> choose calendar, addressbook, mailer etc independantly, and still have
> a fully integrated PIM suite.

We definitely agree on this. There is enought room for any kind of 
specialization or customization for different user target groups on the 
application level, without need to do all the data I/O and manipulation 
multiple times.

Actually both big Free Software desktops have had this goal within the 
respective platform for years, so to share between them and independent 
projects is almost a logical step.

> This would also ease common tasks like synchronization. For example,
> not every PIM suite would have to write its own OpenSync plugin, but a
> single plugin implementing the spec would be enough for all PIM
> solutions.

As far as I understand the OpenSync framework already allows this to some 
extent, i.e. using the same device plugin independent from whether it sync to 
a KDE based local store or that of another PIM project.

But of course sharing both sides would be even better, especially since the 
way users expect synchronization to work has moved from explicit syncing to 
happening implicitly (automatically) in the background.

> I was made aware that Akonadi may actually aim towards this goal, and
> might be interested in not only supporting KDE but being desktop
> independant.

Yes, Akonadi is intended and has been designed to be desktop independent.
The central core is basically specified by a data transport protocol and D-Bus 
interfaces for out-of-band communication (notifications, etc).

There is a desktop independent implementation of the service side (Akonadi 
server), currently hosted in the KDE SVN module kdesupport (software in there 
cannot have any KDE dependency since it has to be built before KDE)

We are trying to get at least some project infrastructure hosted on 
freedesktop.org, but the administration team there doesn't seem to have a lot 
of time, i.e. we are already waiting for about four months now [1]

In the mean time we will have the option to get KDE SVN accounts for external 
contributors should anybody be interested in contributing to Akonadi on any 
level.

As for the client side, we concentrated on doing a KDE based client library 
implementation first. It allowed us to move more quickly since we could 
leverage a lot of functionality already present in KDE libraries.

Earlier this year we tried to find somebody interested in doing a GLib based 
client library as a Google Summer of Code project which we would have 
allocated one of KDE's slots to as a contribution to interoperability, 
however unfortunately we didn't get any application for that idea, dispite a 
couple of GNOME developers helping us with that.

> What is your current view on this? Is Akonadi aiming to have no KDE
> dependancies, and provide services also for non-KDE programs?

Definitely!
Even the several year old initial concept diagram emphasises that :)
http://pim.kde.org/akonadi/

The server is already implemented without any desktop specific things, even 
without GUI portions of Qt, basically just using the GLib level Qt 
equivalents of a GTK+ library stack.

If you and/or others are interested in implementing a GLib based and GLib 
style (e.g. behaving like a GLib using developer would expect), I suggest we 
try to schedule an IRC meeting so that interested developers and people with 
more internal Akonadi knowhow than me (e.g. Till and Volker) have time for 
analyzing requirements, etc.

Of course you are welcome on freenode channel #akonadi at all times :)

> Note that many useful tasks would probably not even require a daemon,
> but could be implemented client-side based on a D-Bus spec.
> Synchronization would be an example, that would mostly just require a
> standardized set of get/add/delete/modify interface methods for
> addressbook, calendar, and notes.

I am not so sure about that.
The daemon/service based approach avoids nasty things like file 
locking/concurrent access, identifier consistency, relyable change 
notifications and so on, though you probably better wait for responses of 
Akonadi architects on any of your questions :)

Cheers,
Kevin

[1] https://bugs.freedesktop.org/show_bug.cgi?id=15711

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