[Kde-pim] Putting Akonadi on the Server?

Mon Dec 19 19:52:38 GMT 2011

On 2011-12-19 18:30, Thomas Koch wrote:
> Georg C. F. Greve:
>> In the scope of our Kolab 3.0 considerations [1] we're also thinking 
>> about
>> putting Akonadi on the server.
> I'm sorry, but I believe this is a bad idea for several reasons:
>

Hi Thomas,

I find your reasoning lacking solid fundamental support for the type of 
argument you are making.

> * As you write, dbus and akonadi are designed and developed for the 
> Desktop.
> Trying to make it work on the server has the potential of conflicts 
> in
> interests between those optimizing for the Desktop (or even mobile)
> and kolab.
>

What do you think is different between personal information management 
on the server, and personal information management on the client? I 
think it is safe to argue that personal information management (i.e 
Akonadi) serves a desktop and server deployment equally well.

> * Akonadi is designed with relational backends in mind. PIM data does
> not fit in relational data stores well and all Groupware systems 
> using those have to
> make some kind of tradeof. (Sparse tables, Entity-Attribute-Value 
> pattern,
> join-hell or structured data in cells)
>

You are making two fundamental mistakes in this reasoning.

It concerns threads / conversations (people's favorite sorting order), 
cross-folder searches, and types of queries often originating from a 
particular UI interaction (i.e. all events for month $x), that are 
queries best executed against a database with relational capabilities.

Another mistake is saying groupware systems using those have to make 
some kind of trade-off. You are confusing the only backend storage 
available to the referred groupware systems exclusively, and a caching 
layer (such as you might imagine Akonadi is a caching layer for 
Disconnected IMAP resources).

> * Kolab already is a complexity beast with so many different systems 
> and
> historical cruft. Please don't add additional systems.
>

This statement in and by itself has no merit, though I understand where 
you're coming from. Rest assured the historical cruft is going out the 
window as soon as possible. Added to that will be some documentation, 
and we already have an open, transparent process for participants in the 
community to contribute through.

That said, however, it leaves me sad to experience not all too many 
people feel like participating in the design, development, testing 
and/or documentation on some of the things we're trying to do.

> The wiki page does not indicate the problem that you try to solve 
> with
> Akonadi. I assume the PHP frontend is not fast enough since PHP does
> not cache state between requests.

Please read the blog post I'm referring to later on, and you can 
recognize why it is we're looking for a particular caching solution. 
Mind you it is not just one or two applications we speak of when wanting 
to abstract a caching layer from the actual application.

> But will things get faster if you need to talk to
> Akonadi which in turn talks to an SQL backend with all the data
> transformations in between and joins in SQLite?

SQLite is the very basic implementation of a SQL database. One can 
imagine this technology to be used on thin provisioned systems. Anything 
that has multiple users is probably better off with some MySQL.

> I just read that SQLite was abandoned for Akonadi since it did not 
> support
> multiple threads.

Better yet, indeed, is to not support it at all.

The key to understanding why Akonadi on the server side is deemed a 
feasible option, is that Akonadi can manage to update itself, as opposed 
to waiting for a web-client UI interaction of sorts, and then descending 
the entire stack + making the necessary iterations.

> What, if the user opens a couple of browser tabs?
>
> In general I think that PHP is not the right tool for many reasons 
> and that
> there are many possibilites to do caching in the JVM between 
> requests. But
> that does not help you right now. What about IMAPProxy?
>
> It would help, if you could describe the original problem.
>

Not a real explanation perhaps, but please consider reading some of my 
own thoughts;

http://planet.ergo-project.org/blog/jmeeuwen/2011/04/16/thoughts-kolab-and-3rd-party-application-caching

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
_______________________________________________
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/