[Kde-pim] Akonadi as a freedesktop.org PIM infrastructure

[Kevin Krammer]

On Wednesday 01 August 2007, Volker Krause wrote:
> On Tuesday 31 July 2007 00:01:44 Kevin Krammer wrote:

> > Basically fd.o has two kind of "roads":
> > =======================
> >
> > (1) shared specification: examples would be menu specification,
> > desktop-entry specification
> >
> > and
> >
> > (2) shared implementation: examples would be D-Bus, HAL

> I think (1) is needed anyway since (2) most likely would only contain the
> server. The client library looks hardly shareable since we use KDE's
> high-level datatypes in there (kcal, kabc, kmime, ...) which most likely
> have native counterparts on other platforms.
>
> And (1) would be a good idea for documentation anyway.

Agreed. Basically it would be either (1 only) or  (1+2). Since you will very 
likely agree that the Akonadi undertaking is not trivial, it will make 
adoption more likely if there is at least a reference/base implementation 
available for shareable components.

> > For (1) "shared specification":
> > ===================
> >
> > Advantages:
> > 	- Akonadi, the code, stays a KDE project
> > 		* we are in control of release dates
> > 		* we have access to KDE infrastructure (we already have commit access)
>
> That's where I see the most critical problem with option (2). Currently
> everyone involved with KDE PIM has a Akonadi checkout and commit rights.
> It's extremely easy for anyone involved with KDE already to contribute to
> Akonadi, no extra account etc. needed. It's build regulary by many people,
> so any breakage (eg. on other platforms) is detected quickly. I doubt any
> of that would be the case with Akonadi being at fd.o.

Foreign infrastructure is basically the biggest impact on the development 
process. It would definitely require to get commit accounts for all people 
currently involved. 

> > For (2) "shared implementation":
> > =====================

> > Disadvantages:
> > 	- political issues
> > 		* "KDE project"
> > 		* dependencies
>
> I'm not really familar with the fd.o process, what's exactly needed to
> become a "standard" there, ie. who would need to be convinced about the
> above mentioned politcal issues?

I think it would be necessary to "ignore" any issues based on the project's 
origin. There will be people who will not like Qt dependencies, however I 
think it is on our interest to go forward with it exactly because of those 
naysayers. It is a bit of a test how open the whole cross-desktop initiative 
really is.

Historically we have been too "shy" about testing these acceptance levels.
If glib is acceptable for use in a C-based daemon project, respective Qt 
modules should be acceptable in a C++ based daemon project.
We just need to be able to demonstrate that clients are not affected by this 
dependencies and I am pondering doing a partial implementation in Java for 
exactly this purpose (i.e. JavaMail store provider, probably mails only)

> > 	- foreign infrastructure
> > 		* need to get respository access on fd.o
>
> How easy is it to get a new account there, assuming we would have Akonadi
> as a project there, ie. similar to KDE or a lengthy application procedure?
> Who is actually in control over the repository there?

Good question. My guess is that once you get a module assigned, it is up to 
the module maintainer to grant access to new developers by changing the 
status of the respective bugzilla request to "confirmed".
At least this is the way Waldo has been getting access for people who wanted 
to contribute to "Project Portland".

> > 		* no l10n or doc-team on fd.o as far as I know
>
> Might not be a big problem for the server, we probably can live without
> translations there.

Right, good point.

> > 	- risk of not being used anyway (see aRts)
> > 	- no nifty kdelibs stuff (e.g. KLocalSocket)
>
> Solveable with a copied "mini kdelibs" (that's ugly of course).

Since this is for some point in the future, it might be possible that Qt 
itself will get a class for local sockets until then.

> > 	- (likely) no sync with KDE releases
>
> Assuming the same people stay in control over Akonadi we could easily sync
> with KDE releases. Which OTOH would also mean we have to do the release
> ourselves while KDE kindly provides that for us. Or is there any fd.o
> central release management?

Not as far as I know. I think the projects hosted at freedesktop.org are not 
related at all, i.e. this is more like hosting at sourceforge, just giving 
the project better visibility and enabling "freedesktop.org marketing bonus"

> > From an engineering point of view the option (1) "shared specification"
> > is probably the better choice. It allows us to proceed on our side as we
> > see fit, only have to make sure we implement the share stuff properly,
>
> Since that is the logical step for option (2) and useful anyway I think we
> should just do it.

Yes, agreed. I haven't used a good phrasing for this, i.e. making it look like 
option (2) would not include/require option (1).
It is definitely required to have a detailed specification for all 
interoperability parts, e.g. D-Bus interfaces, data connection/protocol, 
files and directories.

> Personally, my main focus wrt. Akonadi is getting it useable for KDE PIM as
> soon as possible. This probably wouldn't change with Akonadi being in a
> different repository, but this definitely means I will stay away from any
> kind of political fighting ;-)

Full ACK. My intention was to get people's feedback on this and to make others 
aware of potential requirements of such a move.
E.g. one of the things we would have to consider is renaming the client 
library a bit, so it is clearly understandable as the KDE way of implementing 
the client side, not the default way (or even worse, the only way).
D-Bus showed how this avoids political issues with language/toolkit bindings 
(e.g. all bindings are in the form of libdbus-$binding, no one is just 
libdbus)

On a related note, I am thinking about working on a patch set for using file 
locations based on the XDG base directory spec, instead of hardcoding 
$HOME/.akonadi

Main advantage would be that potentially having a priority sorted list of 
(config) directories allows distributors and/or admins to ship/deploy default 
configurations suitable for their setup. A bit like what we are used to in 
KDE, just on the scope of whole files for now.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070817/2bc62457/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/