|Summary:||Project infrastructure for desktop PIM service Akonadi|
|Product:||freedesktop.org||Reporter:||Kevin Krammer <kevin.krammer>|
|Component:||Project Creation Requests||Assignee:||fd.o Admin Massive <sitewranglers>|
|Status:||RESOLVED WONTFIX||QA Contact:|
|Priority:||medium||CC:||dgollub, lemma, mail, marcus, rdieter, tomalbers, toscano.pino, tuju|
|i915 platform:||i915 features:|
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.