From kde-pim Thu Nov 27 12:33:47 2014 From: Daniel =?ISO-8859-1?Q?Vr=E1til?= Date: Thu, 27 Nov 2014 12:33:47 +0000 To: kde-pim Subject: Re: [Kde-pim] PIM Sprint report: Akonadi Next Message-Id: <9915976.Qt9SLCBWfr () thor> X-MARC-Message: https://marc.info/?l=kde-pim&m=141709165105749 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============7871421104066853461==" --===============7871421104066853461== Content-Type: multipart/signed; boundary="nextPart1505812.Iks0pXGh3x"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart1505812.Iks0pXGh3x Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Wednesday 26 of November 2014 15:22:31 Sebastian K=FCgler wrote: > On Wednesday, November 26, 2014 14:35:00 Sandro Knau=DF wrote: > > > Releasing a library without any ABI guarantees is like not releas= ing a > > > library at all, no? What is Plasma, Ktp, ... actually using from > > > Akonadi? > > > Could maybe a small shim library be created, specifically for tha= t > > > purpose, > > > which can be shipped with an ABI guarantee? Then the rest can be = changed > > > at > > > will and these "external" apps can live happily. For KDEPIM and t= he > > > other > > > "heavy lifters", which will definitely require more access to Ako= nadi > > > API, > > > that is not such a big deal. Since that will probably be released= > > > together > > > with Akonadi anyways, no? And it was/is planned to make more stuf= f > > > internal > > > anyways, right? > >=20 > > The main thing why i think we should not guarntee API/ABI is that b= ig > > parts > > of the codebase of kdepim* should be refactored. But if we wait ti= ll this > > is done, we won't have any new version within the next two or three= years. > > If we release a non API/ABI compatible version, it is possible for = others > > to use the new kdepim like Plasma, Ktp, ... and we can shake out bu= gs with > > the teamplay with these projects. And stopping other parts of KDE i= s no > > nice thing at all. > >=20 > > For external that need ABI guarntee they must stay at the 4.14 for = the > > moment. > >=20 > > I would be very interessed in the thoughts about this from the plas= ma and > > ktp team. >=20 > The bottom line, and really all it boils down to, is that we want to = be able > to use PIM data to integrate into the workspace experience, and into = other > apps. How exactly that's done? There's a lot of room for solutions fr= om our > side. I library with more guarantees (protocol stability, API, ABI, > behavioral consistence, actively developed) is of course better than > missing out on any of these things, but are all of them strictly nece= ssary, > for the whole footprint of kdepimblis? I don't know, we'd have to tal= k > details for that. You can't have your own library to interact with Akonadi, because Akona= di=20 Server (which would your library talk to) is no longer "public API". Th= e only=20 way to use Akonadi now is through the client libraries, with server bei= ng an=20 implementation detail. To sum up, we have three options now: 1) We release what we have now in master, and stop caring, focus workin= g=20 primarily on "Akonadi 2" and come back in a year or two.=20 2) We keep working fulltime on current Akonadi, improving it, bugfixing= ,=20 redesigning and we come up with libraries with stable API/ABI in reason= able=20 timeframe, then start working on "Akonadi 2" while keep maintaining "Ak= onadi=20 1" for bugfixes. At some point we silently replace Akonadi 1 with Akona= di 2=20 and provide API compatibility layer, which we will maintain until we ar= e=20 allowed to change API/ABI again in KF6.=20 3) We do some functional changes and smaller API changes to master, rel= ease it=20 without any ABI guarantees and we keep doing new releases with bugfixes= and=20 small improvements, while working on "Akonadi 2". Once "Akonadi 2" is r= eady,=20 we release it with stable ABI, release an API compatibility layer for e= xisting=20 applications and start slowly porting them away to the new API. Option 1) is no go obviously. Option 2) is doable given the size of the= team,=20 but would mean that "Akonadi 2" would take much more time. Option 3) is= IMO=20 the best option we have, as it allows us to keep providing users good P= IM=20 experience, while not killing of "Akonadi 2" completely.=20 I understand all the concerns of ABI or API breakage, but we can simply= make=20 sure to always inform interested parties about the change, send patches= and=20 help with porting. Since PIM and Plasma would have different release da= tes, we=20 can easily force distros to rebuild necessary parts of Plasma (and othe= r=20 parts) against new PIM through soname bumps. It's some additional work = for=20 packagers, but not *that* much. Dan >=20 > Cheers, =2D-=20 Daniel Vr=E1til | dvratil@redhat.com | dvratil on #kde-devel, #kontact,= #akonadi Software Engineer - KDE Desktop Team, Red Hat Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 --nextPart1505812.Iks0pXGh3x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUdxotAAoJEMWdYU9vSuNI1KYH/2U6NrGdFqWc+hEvmhWAt+Kx j0Y88e5kOi5E4ZewLzh19AyU/3wftAzOdTn+MVhuJi4YGOKy46hNh9cBapYPZm/r n2bntMYCkGOJ5zle/xhNIMLGweCb/bUjczxqk5onwOlFM/MDNHDwWXQUk8U/WKos 8t5kvMC58gBS8Y3JSdbWd2S3F0rIURrmGsm9KZTnYLJp0aPOurmc/weCmNWKv7ml zrh6iIybhnmKmbH5yh9WvdeXUk/eB2bVnDPVJ/rv0RP3jCroW5rHv94j2qawbJb9 VP4JhFffnO2oq1F6edxZ2a+PGJuZxuVIvfC5edcUrbAEjGGbQ1HQw4TirZ/oS7o= =u5Xy -----END PGP SIGNATURE----- --nextPart1505812.Iks0pXGh3x-- --===============7871421104066853461== 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/ --===============7871421104066853461==--