From kde-pim Fri Aug 17 18:27:43 2007 From: Kevin Krammer Date: Fri, 17 Aug 2007 18:27:43 +0000 To: kde-pim Subject: Re: [Kde-pim] Akonadi as a freedesktop.org PIM infrastructure Message-Id: <200708172027.48075.kevin.krammer () gmx ! at> X-MARC-Message: https://marc.info/?l=kde-pim&m=118737532803517 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1237204319==" --===============1237204319== Content-Type: multipart/signed; boundary="nextPart2370279.WeWNl8itmu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2370279.WeWNl8itmu Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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": > > =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 > 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 ver= y=20 likely agree that the Akonadi undertaking is not trivial, it will make=20 adoption more likely if there is at least a reference/base implementation=20 available for shareable components. > > 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 > 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. =46oreign infrastructure is basically the biggest impact on the development= =20 process. It would definitely require to get commit accounts for all people= =20 currently involved.=20 > > 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 > > 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= =20 origin. There will be people who will not like Qt dependencies, however I=20 think it is on our interest to go forward with it exactly because of those= =20 naysayers. It is a bit of a test how open the whole cross-desktop initiativ= e=20 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=20 modules should be acceptable in a C++ based daemon project. We just need to be able to demonstrate that clients are not affected by thi= s=20 dependencies and I am pondering doing a partial implementation in Java for= =20 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= =20 the module maintainer to grant access to new developers by changing the=20 status of the respective bugzilla request to "confirmed". At least this is the way Waldo has been getting access for people who wante= d=20 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=20 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 no= t=20 related at all, i.e. this is more like hosting at sourceforge, just giving= =20 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 l= ike=20 option (2) would not include/require option (1). It is definitely required to have a detailed specification for all=20 interoperability parts, e.g. D-Bus interfaces, data connection/protocol,=20 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 ;-) =46ull ACK. My intention was to get people's feedback on this and to make o= thers=20 aware of potential requirements of such a move. E.g. one of the things we would have to consider is renaming the client=20 library a bit, so it is clearly understandable as the KDE way of implementi= ng=20 the client side, not the default way (or even worse, the only way). D-Bus showed how this avoids political issues with language/toolkit binding= s=20 (e.g. all bindings are in the form of libdbus-$binding, no one is just=20 libdbus) On a related note, I am thinking about working on a patch set for using fil= e=20 locations based on the XDG base directory spec, instead of hardcoding=20 $HOME/.akonadi Main advantage would be that potentially having a priority sorted list of=20 (config) directories allows distributors and/or admins to ship/deploy defau= lt=20 configurations suitable for their setup. A bit like what we are used to in= =20 KDE, just on the scope of whole files for now. Cheers, Kevin =2D-=20 Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring --nextPart2370279.WeWNl8itmu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGxeiknKMhG6pzZJIRAlrOAKCGmzQ+wcyHCPTCSU4Ye/dedphxogCfSBZD s762fafjyN7nb1fpBSduUBc= =XzJq -----END PGP SIGNATURE----- --nextPart2370279.WeWNl8itmu-- --===============1237204319== 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/ --===============1237204319==--