For the last couple of years a team of KDE PIM developers has been working on a PIM data desktop service intended to be used across different desktop environments, called Akonadi
Current website is http://pim.kde.org/akonadi/
As of earlier this week the developers have removed the last KDE dependencies and moved the main service component, the Akonadi server, to a SVN module in KDE's SVN which is used for software KDE depends on, but which do not have any KDE dependencies themselves (http://websvn.kde.org/trunk/kdesupport/akonadi/).
There are still some namespace related things to clean up though, e.g. D-Bus interface names.
Current project infrastructure is hosted by KDE, which could create the false impression that is only intended to be used by KDE.
Client-side the project currently only has a KDE based library implementation. An attempt to get students interested in doing a GLib/GObject based one as a Google Summer of Code project didn't receive any applications, despite very helpful GNOME developers trying to find a co-mentor for GLib specific questions.
The development team is currently about half a dozen people, assisted by KDE developers on matters of build system and build failures, including cross-platform issues: http://cia.vc/stats/project/kde/akonadi
In case of questions, Akonadi developers can usually be reached on IRC channel #akonadi, freenode network
Howdy, what would you be after from fd.o? repo, web? etc...
if possible we would like to host all project activities on fd.o:
- web so we can migrate the desktop neutral information from its current
location on KDE's web server and as a download location for release tar balls.
we already have a domain akonadi-project.org, currently pointing to the KDE
location, in case this makes any difference for you
- an "Akonadi" product in the bugtracking system with a "Server" component (so
we have the option of adding components for desktop independent client
implementations, e.g. Java)
- a developer mailinglist, e.g. akonadi-devel, which should also receive the
- git repository
regarding the repository we do have a question on account creation: since, if
I understand correctly, accounts are managed by the site wrangler team, how
long does it usually take to get contributors approved? (we are kind of
spoiled by how quick KDE's sysadmins handle this :))
fd.o admins: Ping?
This project deserves to either be hosted or be told why it won't be. Even if the hosting can't be set up instantly (e.g. due to sysadmin time/energy right now), a definitive answer should be provided in such a case as this. Three months is too long to be waiting for an answer IMHO.
Thanks in advance ...
(I'm dealing with this now, have talked to Aaron.)
4 months later... ping fd.o admin?
closing as WONTFIX at least for the moment, based on an irc discussion with cornelius schumacher:
* akonadi does not have wide adoption outside kde at the moment, and discussions with various people a while ago revealed a number of concerns about it
* lack of at least a proof-of-concept non-c++ implementation is a bit of an issue
* the main concern raised was the breadth of akonadi's scope; it's possible that a hypothetical cross-desktop solution would end up being a subset of akonadi and used by both akonadi and other desktop projects
the akonadi guys are going to go and talk to the others and try to work out how to go forward, and then we'll see how it goes. so, closing without prejudice based on mutual agreement.
sorry it's taken so long; that's entirely my fault.
Just for the record: I think most of the concerns are based on misunderstandings about what Akonadi is and does. Its intention, design and implementation are cross-desktop from the beginning and it doesn't have any KDE dependencies. But it's appreciated that freedesktop.org takes concerns seriously, so as Akonadi hosting itself is not a problem at the moment, I agree that it's better to close the request for now.
(In reply to comment #6)
> closing as WONTFIX at least for the moment, based on an irc discussion with
> cornelius schumacher:
> * akonadi does not have wide adoption outside kde at the moment, and
> discussions with various people a while ago revealed a number of concerns about
now that we're using this as a criterion (certainly weren't in the past =), a clear definition of what "wide enough adoption to count" means. personally, i believe the only place adoption rates should matter is when being considered for standardization, when using the fd.o namespace in e.g. DBus interfaces, etc.
> * lack of at least a proof-of-concept non-c++ implementation is a bit of an
this is a non-issue. you interact with it out of process using protocols (IMAP, D-Bus), so you can write in C or Java or Ruby or Python or whatever language and use akonadi just fine.
> * the main concern raised was the breadth of akonadi's scope; it's possible
> that a hypothetical cross-desktop solution would end up being a subset of
> akonadi and used by both akonadi and other desktop projects
is this a request for the definition of an "akonadi core"?
> the akonadi guys are going to go and talk to the others and try to work out how
> to go forward, and then we'll see how it goes. so, closing without prejudice
> based on mutual agreement.
To avoid misconceptions about Akonadi for those who were not part of the
discussion and are only reading this comments we'd like to responde to the
items presented above.
> * akonadi does not have wide adoption outside kde at the moment, and
> discussions with various people a while ago revealed a number of
> concerns about it
As for the adoption, we had assumed that part of freedesktop.org's goals
was to make cross-desktop solutions to common problems more known outside
the original conception, e.g. GStreamer moving from GNOME infrastructure
to here in order to avoid mistakingly being assumed to contain GNOME
As for the "various concerns", you find us quite surprised and puzzled.
If there had been a number of concerns voiced by several people, surely
those concerns would have been communicated with us.
Concerns not known to us can obviously not be addressed or even less
> * lack of at least a proof-of-concept non-c++ implementation is a
> bit of an issue
Nothing at http://www.freedesktop.org/wiki/MissionStatement hints that system
or session daemons, being language neutral by virtue of communication through
open protocols, would be required to have a non-c++ implementation.
As for the client library, the KDE based one will obviously be hosted at KDE
since it is part of the KDE application framework.
We have actively tried to get one at least started based on a C/GLib stack,
e.g. by reserving a Google Summer of Code slot allocated to KDE for that
task. Unfortunately no student applied for this project.
However we continue to explore options for making alternative client library
> * the main concern raised was the breadth of akonadi's scope; it's
> possible that a hypothetical cross-desktop solution would end up
> being a subset of akonadi and used by both akonadi and other desktop
Most likely a misunderstanding of the project or its goals.
Akonadi's main purpose is to be a cache for PIM data, like a web proxy between
end user application and actual data source.
Therefore the shared component which we assumed would best be hosted at a
shared site would have been the Akonadi Server, the process managing the
cache and Akonadi Control, the process knowing where to find helper processes
and how to start them.