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

[Volker Krause]

On Tuesday 31 July 2007 00:01:44 Kevin Krammer wrote:
> at aKademy I talked to at least Cornelius and Till about Akonadi becoming a
> freedeskop.org "standard" for PIM data handling.

As Cornelius already noted, this was considered from the beginning, that's why 
eg. the server still has no KDE dependencies. However, I doubt anyone thought 
about the concrete problems (see below) this might cause ;-)

> 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
>
> Both can result in the other, e.g. D-Bus also specifies protocol and
> semantics and there are independent implementations for client lib and
> server.

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.

> Each option has its own advantages and disadvantages. In the context of
> Akonadi I came up with these (definitely not complete):
>
>
> 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.

> 		* we can have KDE dependencies
> 	- less political  issues, e.g. dependencies
> 	- extensions can be added as KDE specific enhancements and specified later
>
> Disadvantages:
> 	- complex problem domain
> 		* makes it hard to implement based on just a spec
> 		* makes it unlikely to be implemented soon outside Akonadi
> 	- different implementations
> 		* need to be cross-tested
> 	- different release cycles
> 		* independent projects (e.g. ISVs) need to wait for all to be completed
>
>
> For (2) "shared implementation":
> =====================
>
> Advantages:
> 	- single codebase
> 		* might get outside KDE contributions
> 	- one release data
> 		* one version per distribution
> 		* might become part of LSB
> 	- more testing
> 		* different client implementations will trigger different bugs
> 	- marketing
>
> 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?

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

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

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

> 	- (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?

> Personal notes:
> ==========
>
> 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.

> Basically this is why KDE usually takes this approach, i.e. offering the
> documentation of our implementations as the input for a problem domain.
>
> Basically this is also why KDE is quite always seen as the follower
> regarding "standards", while most current "standards" are either based on
> KDE specs (e.g. desktop-entry) preceeded by KDE's work (e.g. DCOP/D-Bus).
> See also item "marketing" in the lists above.

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 ;-)

regards
Volker
-------------- 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/20070801/7e20a479/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/