[Kde-pim] PIM Sprint report: Akonadi Next

[Milian Wolff]

On Wednesday 26 November 2014 10:46:18 Daniel Vrátil wrote:
> Hi all,
> 
> the PIM sprint is over and we have some exciting future ahead of us!
> 
> Let's start with the largest change: Christian and Aaron came up with a
> proposal for redesign of Akonadi using modern reactive design patterns. We
> polished and sorted out a lot of details there, and I'm really excited about
> the plan, as it will allow Akonadi to benefit from modern technologies,
> making the codebase simpler, faster and more robust (I guess that's what
> you guys said about the current Akonadi too ;-)). We also hope to attract
> new contributors by using the new "cool" stuff. Big thanks to Till for his
> insights into current Akonadi design.

Can you share some more about the ideas you have? This teaser above has me 
hooked, but it doesn't really say that much about what you guys are up to :)

> Implementing these changes and stabilizing the project will take lots of
> time. On Akademy I mentioned that my plans I had with Akonadi would take
> roughly a year to implement. I expect that this will take at least the same
> amount of time, maybe even more, since I'll have considerably less time to
> work on PIM in the near future. I gave some thoughts to the current
> situation and I think that it might be a good idea to implement some of my
> ideas on the current Akonadi master, and release as soon as possible, so
> that people can get at least some bug fixes and performance improvements
> while we work on the "Akonadi Next". Since KDE PIM is basically ported to
> Qt 5/KF 5 (with kdelibs4support, but that does not really matter) and seems
> to work (more or less), we could try to release from master with next KDE
> Applications (15.04 or whatever the version turns out to be) without any
> guarantees and promises of API and ABI compatibility of the Frameworks.
> This is necessary, because we can't really wait with release until we can
> give this promise, as there are other projects depending on Akonadi
> (Plasma, KTp, ....) and we are effectively blocking them. Once we decide
> that the new Akonadi is ready, we should be able to simply switch from the
> old one to the new one and work towards stable API/ABI of the libraries.
> Laurent, and other PIM maintainers: opinions?

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?

> We also discussed some more repositories reshuffling:
> 
> kdepimlibs:
> * merge akonadi-{contacts,calendar,mime,notes,socialutils} to akonadi-extras
> * merge gpgme++ and qgpgme
> * finish killing kpimutils
> 
> kdepim-runtime:
> * agents -> akonadi-resources
> * resources -> akonadi-resources
> * plugins -> akonadi-extras
> * qml -> akonadi (src/declarative)
> * resourcetester -> akonadi-resources
> * kioslave -> could go to kio-extras, or akonadi-extras
> * migration -> akonadi-migration
> 
> kdepim:
> - no changes atm
> 
> I'm not mentioning the other topics like VDG and QML API as I wasn't there
> or wasn't paying enough attention :), but I hope others who were there will
> send their summary too.

Sounds like an interesting sprint! Rock on guys
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
_______________________________________________
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/