Bug 15711 - Project infrastructure for desktop PIM service Akonadi
Project infrastructure for desktop PIM service Akonadi
Status: RESOLVED WONTFIX
Product: freedesktop.org
Classification: Unclassified
Component: Project Creation Requests
unspecified
All All
: medium normal
Assigned To: fd.o Admin Massive
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-25 10:18 UTC by Kevin Krammer
Modified: 2009-08-07 05:24 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Krammer 2008-04-25 10:18:46 UTC
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
Comment 1 Benjamin Close 2008-06-27 03:40:24 UTC
Howdy, what would you be after from fd.o? repo, web? etc...
Comment 2 Kevin Krammer 2008-06-28 07:51:16 UTC
Hi,

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 
bugtracker notifications

- 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 :))
Comment 3 Aaron Seigo 2008-07-27 10:44:15 UTC
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 ...
Comment 4 Daniel Stone 2008-07-27 15:49:58 UTC
(I'm dealing with this now, have talked to Aaron.)
Comment 5 Sebastian Sauer 2008-11-25 06:48:12 UTC
4 months later... ping fd.o admin?
Comment 6 Daniel Stone 2009-01-08 07:38:12 UTC
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.
Comment 7 Cornelius Schumacher 2009-01-08 13:35:16 UTC
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.
Comment 8 Aaron Seigo 2009-01-14 13:53:45 UTC
(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
> it

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

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.

cool ...
Comment 9 Kevin Krammer 2009-01-20 12:05:10 UTC
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
dependencies.

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

>  * 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 
implementations happen.

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

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.