[Kde-pim] PIM Sprint report: Akonadi Next

[Christian Mollekopf]

On Wednesday 26 November 2014 15.12:23 Sebastian Kügler wrote:
> Hi PIMsters,
> 

Hi Sebastian,

> 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.

> - 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)

> - 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.

> - 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.
> 

?

> - 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.

> 
> 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.

> 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).

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.

Cheers,
Christian

_______________________________________________
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/