[Kde-pim] PIM Sprint report: Akonadi Next

[Daniel Vrátil]

On Wednesday 26 of November 2014 15:22:31 Sebastian Kügler wrote:
> On Wednesday, November 26, 2014 14:35:00 Sandro Knauß wrote:
> > > Releasing a library without any ABI guarantees is like not releasing a
> > > library at all, no? What is Plasma, Ktp, ... actually using from
> > > Akonadi?
> > > Could maybe a small shim library be created, specifically for that
> > > 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 the
> > > other
> > > "heavy lifters", which will definitely require more access to Akonadi
> > > 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 stuff
> > > internal
> > > anyways, right?
> > 
> > The main thing why i think we should not guarntee API/ABI is that big
> > parts
> > of  the codebase of kdepim* should be refactored. But if we wait till 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 bugs with
> > the teamplay with these projects. And stopping other parts of KDE is no
> > nice thing at all.
> > 
> > For external that need ABI guarntee they must stay at the 4.14 for the
> > moment.
> > 
> > I would be very interessed in the thoughts about this from the plasma and
> > ktp  team.
> 
> 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 from 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 necessary,
> for the whole footprint of kdepimblis? I don't know, we'd have to talk
> details for that.

You can't have your own library to interact with Akonadi, because Akonadi 
Server (which would your library talk to) is no longer "public API". The only 
way to use Akonadi now is through the client libraries, with server being an 
implementation detail.

To sum up, we have three options now:

1) We release what we have now in master, and stop caring, focus working 
primarily on "Akonadi 2" and come back in a year or two. 

2) We keep working fulltime on current Akonadi, improving it, bugfixing, 
redesigning and we come up with libraries with stable API/ABI in reasonable 
timeframe, then start working on "Akonadi 2" while keep maintaining "Akonadi 
1" for bugfixes. At some point we silently replace Akonadi 1 with Akonadi 2 
and provide API compatibility layer, which we will maintain until we are 
allowed to change API/ABI again in KF6. 

3) We do some functional changes and smaller API changes to master, release it 
without any ABI guarantees and we keep doing new releases with bugfixes and 
small improvements, while working on "Akonadi 2". Once "Akonadi 2" is ready, 
we release it with stable ABI, release an API compatibility layer for existing 
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, 
but would mean that "Akonadi 2" would take much more time. Option 3) is IMO 
the best option we have, as it allows us to keep providing users good PIM 
experience, while not killing of "Akonadi 2" completely. 

I understand all the concerns of ABI or API breakage, but we can simply make 
sure to always inform interested parties about the change, send patches and 
help with porting. Since PIM and Plasma would have different release dates, we 
can easily force distros to rebuild necessary parts of Plasma (and other 
parts) against new PIM through soname bumps. It's some additional work for 
packagers, but not *that* much.

Dan

> 
> Cheers,

-- 
Daniel Vrátil | dvratil at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141127/fd38ccf2/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/