Re: Fwd: akonadi 4 & 5 not coinstallable !

Kevin Krammer <[email protected]> Sun, 10 Jan 2016 14:00:03 +0100
Newsgroups	gmane.comp.kde.users.pim
Organization	KDE
Message-ID	<2944834.RKUukJDDRN@persephone>
On Friday, 2016-01-08, 12:15:04, Lindsay Mathieson wrote:
> On 27/11/15 07:07, Daniel Vrátil wrote:
> > We realize there are still some KDE4-based applications that need Akonadi
> > and their port to KF5 is still underway (or not even started) and we
> > understand that it may cause problems to some users. However the major
> > changes that we did allowed us to move forward in a way that would not be
> > otherwise possible. The performance gain and memory usage optimizations
> > alone were absolutely worth it, not mentioning the improved
> > maintainability and robustness of the entire thing. To me this is a price
> > worth paying.....
> 
> I thought that was what the port from 3 to 4 was supposed to achieve.

Assuming "3 to 4" means the move from in-process backend access to Akonadi, 
then the main goals for that move were unification and arbitration of access.

In-process backend access, i.e. each application reading/writing 
calendar/contact/mail files, had proven to be very difficult to get right , 
(requiring file locking, which is not available reliably on all file systems. 
etc).

Direct access also meant that you needed KMail to interact with mails, e.g. 
for accessing contact/calendar data on a Kolab server.

Akonadi solved these two major hurdles by providing a central "go-to" service.
It would arbitrate between applications accessing the same data (e.g. avoid 
overwriting each other's changes) and enabled any application to handle all 
data it wanted to, i.e. enabling end user application developers to deal with 
data access in a uniform way independent of the actual backend it is being 
stored on.

Originally [1] the goal was to provide that as a hub for all applications, 
i.e. additional to the application of KDE PIM also to any other application, 
e.g. Plasma Shell, newly developed UIs like Zanshin, etc.

The first implementation of a new architecture is often not the best possible 
one, so the new implementation's goal is to improve the less efficient bits 
while keeping a lot of the overall concepts.

Cheers,
Kevin

[1] Akonadi has sadly dropped it and is only aiming at being a backend for KDE 
PIM apps now

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users
signature.asc (application/pgp-signature, 819 B)