[Kde-pim] PIM Sprint report: Akonadi Next

Wed Nov 26 16:04:40 GMT 2014

Hi Christian,

Thanks for the quick, insightful reply. I think some misconceptions stem from 
the limited information I had available (the slides provided, this thread), so 
I gladly stand corrected. :)

On Wednesday, November 26, 2014 15:47:08 Christian Mollekopf wrote:
> On Wednesday 26 November 2014 15.12:23 Sebastian Kügler wrote:
> > On Wednesday, November 26, 2014 13:16:49 Daniel Vrátil wrote:
> > > Aaron has also shared some slides [0] that Christian presented on the
> > > sprint  regarding this change
> > > 
> > > [0] https://plus.google.com/+AaronSeigo/posts/Xt7HNZJV5UJ
> > 
> > The proposed plan worries me. If the port to KF5 and the radical redesign
> > which is proposed go together, which they do (the port is just a dev
> > cycle,
> 
> > no release, so it's not a user-visible artifact), that means the 
following:
> The port and the new design do not go together.

Ok, that's what I understood from the slides. (Slide 24 (Timeline) says that 
the Qt5/KF5 port would be "not a release cycle, just a dev cycle". There's 
some bits (especially the client APIs, but preferably also the "whole package" 
which we'd like to see in their Qt5/KF5 version rather sooner than later, so 
we can integrate our KF5-based code with features Akonadi offers. (Think 
KPeople synching contacts over Akonadi, calendaring in Plasma, etc..)

> > - Less branches to maintain, there's stable (KDE4libs-based) and there's
> > dev (KF5-based, akonadi redesigned from a certain point, etc.)
> 
> The new akonadi would only be on top of KF5. Porting first, then new
> akonadi.

> > - For Plasma, we'll have to ship the KDE4libs-based version forever (or at
> > least until the transition is done and stabilized, from experience and
> > given the current strength of the community, 4 years?
> 
> Meaning you need the current akonadi api for the next 4 years working?
> (that is something we might provide, so that's an actual question)

For our development base, that's not so much an issue. I'm happy if we can 
hook into calendaring, addresses, etc. and be able to configure these things 
for example from Systemsettings 5. 
So no, I don't think we need current Akonadi work in five years. From a distro 
/ end user point of view, that's a different story -- and you probably know 
better than me what it entails.

> > - We'd need a way to access and integrate data from the KDE4libs-based
> > Akonadi stack, such as calendaring, addressbooks, and perhaps at some
> > point
> > even email (I'd like to revive Lion Mail somewhen, I don't see how I could
> > do that with the proposed plans still within my event horizon.) The
> > current
> > plan almost forces us to reconsider integrating Plasma with KDEPIM, and go
> > look for other solutions.
> 
> While I understand your worries, I think you're jumping the gun. No
> decisions have been taken and we'll certainly consider things like
> providing a smooth transition for existing akonadi users.

I understood that, your presentation was clearly marked as a proposal. I tried 
not to jump the gun, but there's a few things in there which made me wonder. I 
wrote my email as to clear them up, which is what we're doing.

> > - Moving to Wayland with a lot of Qt4 baggage will be hard. Add a ton of
> > other things why we'd need Qt5 to that.
> 
> ?

More of a general remark about benefits of Qt5, one of which being that we 
need either a Qt5-based app (Kontact) or use XWayland to be able to provide a 
KDEPIM on top of Wayland. Qt5 makes it a lot easier. Not directly related 
here, so I think it can be safely ignored at this level of detail. :)

> > - The plan may make sense for enterprise scenarios, where a migration to
> > PIM/5 is realistically many years away, but users who'd like to lift their
> > whole stack to Qt5/KF5 before that?
> 
> If the new akonadi materializes, we'll certainly consider existing users.
> And no, I don't plan on repeating the experience of the transition to
> akonadi.

Good. :)

> > To me, the plan proposed does not sound like its considering the full user
> > and stakeholder base. There's also no sufficient transition plan that
> > solves our (Plasma's) problems. The most positive thing that came up (and
> > not in the proposal, but in this thread, is a library without any
> > guarantees). That's not very encouraging for something as sensible and
> > central to the user experience as personal data.
> 
> Please consider that we're in a very early design stage, and while we do not
> yet have all answers, we're working on it.

Sure, that's why I'm chiming in sooner rather than later, I saw holes in the 
plan which raise questions. It's becoming a bit clearer, and less worrying 
now.

> > So, how would a perfect transition look like from my POV:
> > - Port as-is to Qt5, Frameworks 5
> > - Stabilize that port, get users to use this port as soon as possible
> > - Do not change protocols, API, etc. there unless really necessary to make
> >   porting easier and reduce the migration cost
> > 
> > - Once there's a stable Qt5-based Akonadi/PIM released, start the redesign
> >   effort, if possible in small steps as to not drift away into
> >   "development
> >   land where there are no users for years to come"
> > 
> > - Once the viability of a redesign has been proven, in terms of
> > architecture, maintenance and migration, make it usable
> 
> We don't differ a whole lot with our plans. The only thing we want to avoid
> is giving BIC guarantees for an API that we'd like to overhaul and is
> mostly used kdepim internally.
> 
> I do expect to write a compatibility layer for the existing API though, so
> we might just keep that working too (we won't be able to port all
> applications to new API in one big step).

Ok, cool.

> Also, we didn't make any decisions yet how we're going to do the transition
> exactly, but when we do I'll make sure that we announce it publicly so we
> can have this discussion.
> 
> > That means to not cobble huge changes in different areas into one huge
> > project, but a baby-steps approach to changes. I think we've seen with the
> > KDE4 transition how well this huge projects work -- they're essentially a
> > good way to endanger a project's future.
> 
> We realize that.

:)

> I understand your concerns, but we are very early in design phase, so it
> will take some time to address them and provide a complete plan. We're not
> ignoring those issues though and will definitely look into them.
> 
> The only thing we'd like to mention at this point is that we'd like to avoid
> releasing an akonadi framework with API/BIC guarantees, because we need to
> overhaul this API and it doesn't seem like a good idea to set it into stone
> for the next 5 years. Apart from that, akonadi has become an implementation
> detail with frameworks, and we're looking into improving that
> implementation detail eventually.

Awesome.

I think from the Plasma side, we'd be able to work with libraries that don't 
have a 5-year-ABI guarantee. We just need something that works, and we can 
update things to work with new architectural features then. Marco has some 
thoughts on this in the neighbouring email.

As more details of these plans become clear, we can discuss specifics about 
that.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
_______________________________________________
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/