Akonadi – still alive and rocking

Posted Jan 12, 2016 10:47 UTC (Tue) by jospoortvliet (guest, #33164)
In reply to: Akonadi – still alive and rocking by drag
Parent article: Akonadi – still alive and rocking

Note that we're on the edge of what I understand about this, technically.

But from my understanding, there's no more central server, but not ALL work is done by the clients, only the reading, which is implemented in a library. Resources (eg IMAP client) are independent processes which retrieve and cache data.

Let me quote
> Basically the new design absents central server in favor of using
> per-resource storage. Each resource would maintain it's own key-value store
> (allowing each resource to store data in a way that is efficient for them
> to work with) and would provide an implementation of standardized interface
> to access this storage directly. Clients would be allowed direct read-only
> access to these storages, while resources are the only one with write
> access. Internally flatbuffers would be used to provide access to the data
> in super-efficient way (lazy-loading, memory mapping, all the fancy stuff).

> Resources would implement pipelines allowing some pre-processing of newly
> incoming data before storing them persistently (think mail filtering,
> indexing, new mail notifications etc.). Inter-resource communication (for
> example to perform inter-resource move or copy), and client->resource
> communication would be done through a binary protocol based on what we have
> now in Akonadi. This design also gives us on-demand start/stop of resources
> for free. Something that requires ridiculous amount of work to make work
> with the current design.

> API-wise, while we can't completely get rid of the "imperative" API of
> having jobs, the core method to provide access to data would be through
> models. Making use of storage data versioning, on update the model simply
> requests changes between current and last revision of the stored data. This
> should prevent us from ending up with overcomplicated beast-models like
> ETM.

See
https://community.kde.org/KDE_PIM/Akonadi_Next/Design
https://community.kde.org/KDE_PIM/Akonadi_Next#Design

https://cmollekopf.wordpress.com/2015/02/08/progress-on-t...
https://cmollekopf.wordpress.com/2015/08/29/bringing-akon...
https://kolab.org/blog/mollekopf/2015/10/22/progress-prot...

Akonadi – still alive and rocking

Posted Jan 12, 2016 16:06 UTC (Tue) by drag (guest, #31333) [Link]

thank you.

Akonadi – still alive and rocking

Posted Feb 9, 2016 4:49 UTC (Tue) by daniel (guest, #3181) [Link]

"from my understanding, there's no more central server..."

And, blessedly, no more relational database. It looks like the new maintainer has a sensible attitude, and the experimental refactoring that is Akonadi might yet prove to be useful. Too bad about sacrificing the entire Kmail user community in the process, myself included. The big lesson here is that there is never a valid reason to perform trapeze without a safety net - kmail2 should have been deployed in parallel with kmail1 until such time as proved to be a complete and viable replacement, just as Apache2 lived beside Apache1 for years.