Hello PIMsters,

at aKademy I talked to at least Cornelius and Till about Akonadi becoming a 
freedeskop.org "standard" for PIM data handling.

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.

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)
		* 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
	- foreign infrastructure
		* need to get respository access on fd.o
		* no l10n or doc-team on fd.o as far as I know
	- risk of not being used anyway (see aRts)
	- no nifty kdelibs stuff (e.g. KLocalSocket)
	- (likely) no sync with KDE releases


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,

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.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/