KDE PIM in Randa

Standard

The first release of KDE PIM based on KDE Frameworks 5 and Qt 5, which will be part of the KDE Applications 15.08 release, is getting closer and closer. Except for porting the entire suite from Qt 4 to Qt 5 the team also managed to fix many bugs, add a few new features and do some pretty big performance and memory optimizations. And we already have some new improvements and optimizations stacked in the development branch which will be released in December!

The biggest performance improvement is thanks to switching to a faster implementation of the communication protocol used by applications to talk to the Akonadi server. We also extended the protocol and we can now use it to send change notifications from the Akonadi server to clients much more effectively than previously. Additionally we started cleaning up API of our libraries and improving it in a way that allows for safer and more effective use. None of this was possible in the KDE 4 version of KDE PIM, where we promised API and ABI compatibility with previous releases. For now we decided not to give any such promises for several more releases, so that we can tune the API and functionality even more.

During Akademy the KDE PIM team had a very long session where we analyzed where the project currently stands and we created a vision of where we want KDE PIM to be in the future. We know what parts we want to focus on more now and which parts are less relevant to us. KDE PIM is a huge and rather complicated project, unfortunately the development team is very small and so we have to make the hard and painful decision to lay off some of the features and functionality in exchange for improvement in reliability and user experience of the core parts of the product.

In order to make these decisions the team is going to meet again in couple weeks in Randa alongside many other KDE contributors and projects and will spend there a whole week. During the sprint we want to take a close look at all the parts and evaluate what to do with them as well as plan how to proceed towards Akonadi Next – the new version of Akonadi, which has some major changes in architecture and overall design (see the Christian’s talk from Akademy about Akonadi Next).

However organizing such sprint is not easy and so we would like to ask for your support by donating to the KDE Sprints Fundraiser. Although the attendees cover some of the costs themselves, there are still expenses like travel and accommodation that need to be covered. This year the Fundraiser has been extended so that the collected money will also be used to support additional KDE sprints throughout the year.

7 thoughts on “KDE PIM in Randa

  1. Kevin Krammer

    How will you handle the compatibility with Qt4 based applications?
    A new Qt4 based and binary compatible libakonadi, an old-protocol handler in the new server or a protocol proxy on the old socket path?

    Or is the plan to run both Akonadi servers in parallel and share the data on the backend?

    • We don’t support running Qt 4 apps with Qt 5 Akonadi. The only application that will be really affected by this is Zanshin, but ervin is working on getting it to Qt 5.

      There are few more apps that have kdepimlibs as an optional dependency, so distros will have to turn that off until they catch up with us.

  2. Kevin Krammer

    So Akonadi will no longer be a PIM data provider for all applications but only the backend handler for KDE PIM?

    The original idea of Akonadi was to provide uniform PIM data access (and potentially other data) to all applications who need it, to make the data and related functionality available outside of the “silos” they had been stuck in before (e.g. mail only accessible by KMail).

    This sharing and integration was once the core selling point of the “KDE desktop experience”, I am sad to see it go.

    • Akonadi server is an implementation detail now, any application that wants to access the storage must go through the client libraries. The libraries currently sit in kdepimlibs repo, but eventually I want to move them to Akonadi git repo, to provide a basically self-contained framework. We want to have other apps using Akonadi, the idea is still there, but we won’t release it as such until we are “done” with it, because that would require ABI/API to compatibility guarantees, which we don’t want to give just yet. I hope that clarifies it a bit :)

      • Kevin Krammer

        The current situation is:
        -Akonadi is a service for access to PIM data
        – it is used for that by KDE PIM applications and other applications

        Now my understanding is that there are plans to change some of the internals, or, as you put, it implementation details.

        However, several indicators suggests that this is not the case.

        You first reply, for example, implies that applications will lose access to PIM data at such a point in time when KDE PIM unilaterally decides it is “their” data now.

        Like early versions of iTunes which didn’t care that moving/renaming a user’s music files would negatively impact other use cases the user might have had until then.

        • There seems to be some misunderstanding. Akonadi (server + client libraries) will eventually become a Framework for any application to use to access PIM data as well as any other data if the applications provide their own resource, serializer plugins etc. – so nothing changes in comparison to KDE 4 situation. What we don’t support anymore is 3rd party developers writing their own client libs to talk directly to the Akonadi server. By server no longer being part of public API, we can change the protocol and server DBus interface in incompatible ways between releases.

          The problem will be with KDE4 applications using Akonadi will lose access to them until they switch to KF5. The data won’t get lost or moved or anything, the application will just not have accesa to them as kdepimlibs4 will simply be unable to talk to Qt5 server. That is a trade-off we had to take in order to be able to move forward with KDE PIM. Otherwise we would linger in the same situation forever just to keep compatibility with KDE4 apps preventing us to do the much much needed optimizations and changes.

          Right now we are releasing the Akonadi server+client libraries as part of Applications and we don’t have any API/ABI guarantees, so at this point 3rd party applications (read apps outside KDE PIM) would have to keep up with our changes. But once things settle down (and it’s hard to tell when that will be right now) we will stabilize and make Akonadi a Framework for anyone to use for whatever they want.

          • Kevin Krammer

            Definitely a misunderstanding, I was not talking about alternative client libraries at all.
            I was talking about existing users of the main client libraries getting “the rug pulled out under them”.

            I see no point in making the new Akonadi a framework if the people working on it do not intend to treat it as such.
            Why would application developers want to use something that has proven to be unreliable?

            Akonadi becomes something application developers will avoid if they care about being able to provide their users with working applications.

            Not having runtime compatibility will also hurt KDE PIM.
            Distributors will have to hold off on packaging the new versions until all programs using Akonadi have been ported.

            Btw, Evolution Data Server changed protocol from CORBA to D-Bus without breaking all applications in the process.
            How? They changed the implementation without changing the API. The new EDS came with client libraries that were API and ABI compatible to the old ones.

Comments are closed.