From kde-pim Wed Aug 01 15:04:34 2007 From: Volker Krause Date: Wed, 01 Aug 2007 15:04:34 +0000 To: kde-pim Subject: Re: [Kde-pim] Akonadi as a freedesktop.org PIM infrastructure Message-Id: <200708011704.37313.vkrause () kde ! org> X-MARC-Message: https://marc.info/?l=kde-pim&m=118598108021794 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============2122718197==" --===============2122718197== Content-Type: multipart/signed; boundary="nextPart5906063.M7XNA0ioOo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart5906063.M7XNA0ioOo Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 eg. the server still has no KDE dependencies. However, I doubt anyone thoug= ht=20 about the concrete problems (see below) this might cause ;-) > Basically fd.o has two kind of "roads": > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > (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=20 server. The client library looks hardly shareable since we use KDE's=20 high-level datatypes in there (kcal, kabc, kmime, ...) which most likely ha= ve=20 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": > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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=20 everyone involved with KDE PIM has a Akonadi checkout and commit rights. It= 's=20 extremely easy for anyone involved with KDE already to contribute to Akonad= i,=20 no extra account etc. needed. It's build regulary by many people, so any=20 breakage (eg. on other platforms) is detected quickly. I doubt any of that= =20 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 lat= er > > 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": > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 beco= me=20 a "standard" there, ie. who would need to be convinced about the above=20 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 a= s a=20 project there, ie. similar to KDE or a lengthy application procedure? Who i= s=20 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=20 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= =20 with KDE releases. Which OTOH would also mean we have to do the release=20 ourselves while KDE kindly provides that for us. Or is there any fd.o centr= al=20 release management? > Personal notes: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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= =20 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= =20 soon as possible. This probably wouldn't change with Akonadi being in a=20 different repository, but this definitely means I will stay away from any=20 kind of political fighting ;-) regards Volker --nextPart5906063.M7XNA0ioOo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGsKEFf5bM1k0S0kcRAl5xAJ9mLBL3JxkCXa9qwnS4CNU6LpLllwCgmTqf sOk5z0ysmBW1MbRZygV3V7U= =MoR4 -----END PGP SIGNATURE----- --nextPart5906063.M7XNA0ioOo-- --===============2122718197== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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/ --===============2122718197==--