--===============0467846324==
Content-Type: multipart/signed;
  boundary="nextPart1273830.VzvrHtXSxy";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1273830.VzvrHtXSxy
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 it=
s=20
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=20
specialization or customization for different user target groups on the=20
application level, without need to do all the data I/O and manipulation=20
multiple times.

Actually both big Free Software desktops have had this goal within the=20
respective platform for years, so to share between them and independent=20
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=20
extent, i.e. using the same device plugin independent from whether it sync =
to=20
a KDE based local store or that of another PIM project.

But of course sharing both sides would be even better, especially since the=
=20
way users expect synchronization to work has moved from explicit syncing to=
=20
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=20
interfaces for out-of-band communication (notifications, etc).

There is a desktop independent implementation of the service side (Akonadi=
=20
server), currently hosted in the KDE SVN module kdesupport (software in the=
re=20
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=20
freedesktop.org, but the administration team there doesn't seem to have a l=
ot=20
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 extern=
al=20
contributors should anybody be interested in contributing to Akonadi on any=
=20
level.

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

Earlier this year we tried to find somebody interested in doing a GLib base=
d=20
client library as a Google Summer of Code project which we would have=20
allocated one of KDE's slots to as a contribution to interoperability,=20
however unfortunately we didn't get any application for that idea, dispite =
a=20
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=
=20
without GUI portions of Qt, basically just using the GLib level Qt=20
equivalents of a GTK+ library stack.

If you and/or others are interested in implementing a GLib based and GLib=20
style (e.g. behaving like a GLib using developer would expect), I suggest w=
e=20
try to schedule an IRC meeting so that interested developers and people wit=
h=20
more internal Akonadi knowhow than me (e.g. Till and Volker) have time for=
=20
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=20
locking/concurrent access, identifier consistency, relyable change=20
notifications and so on, though you probably better wait for responses of=20
Akonadi architects on any of your questions :)

Cheers,
Kevin

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

=2D-=20
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

--nextPart1273830.VzvrHtXSxy
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBIptFNnKMhG6pzZJIRAu4eAJ0fa0xzgqFUHrkUNFLhpkGqwpj0SACeJ1Wb
YdL6VXfds7+hrPMOAtngHCg=
=llHN
-----END PGP SIGNATURE-----

--nextPart1273830.VzvrHtXSxy--

--===============0467846324==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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/
--===============0467846324==--