kde-pim dev needed, for a sponsored open source effort, to remove akonadi

[René J.V. Bertin]

On Friday March 16 2018 17:37:27 E. Hakan Duran wrote:
[...]
>My 2-cents worth opinion is that the tools needed to make a PIM suit work with a database backend were truly not available when this decision was made. Nepomuk, strigi, baloo, akonadi have different associations for me than say vi, gpg, bash. While the latter are meant to represent a stable, dependable and do-the-job-right-at-the-first-time kind of software, the former represent everything but those. And when the foundation is not stable, this is what you get. Since my thoughts are just from a user perspective, my conclusion may not be very accurate, and I apologize if I offend any dev due to those.
[...]
>I am sorry to occupy your inboxes with my long blabbering. 

No apologies needed IMHO. You highlight something that is both the advantage and the curse of open source desktop environments or components thereof. They evolve because there's no or less commercial interest behind them so they can be test-beds for new ideas, gimmicks and new developers (how many components were the subject of masters' or PhD theses?). The drawback is that this can make them much less friendly for regular users, in part because there isn't always a central design/development policy that's truly centred on providing a stable and reliable user experience. The whole transition to KF5 was an example of that in my eyes which kind of reminded me of the early MS-Dos days where new releases rained down each introducing a much-needed new feature. But much as I like what I can do with KMail it has always been focussed on something that doesn't include 100% practicality - I'm thinking here of the refusal to implement something like an IMAP prefix which most other email clients provide to work with certain older types of servers.

I've come the KDE because of KMail which I knew from Linux (at the time really a secondary OS for me) but which proved to be a suitable replacement for Apple Mail when that application started to force me to download all my email to a local copy in a local database (sound familiar?) -- even the archived email I keep in IMAP folders on the same host. I'm now on KDEPIM 4.14 with some personal hacks and backports, and will apparently either stay there or be obliged to move on to something else (the dependency on QtWebEngine in the current KDEPIM is a no-go for me.)

On Friday March 16 2018 22:07:47 Pablo Sanchez wrote:
> That is, to make it performant I don't 
>think there is much effort.  That is what we were talking about.  I think 
>you misunderstood something.

No, I think you misunderstood something - the way I understand this thread it measures performance as the extent to which KDEPIM does what you expect from it, with speed only part of the equation.

But you may have a point in the sense that in complex asynchronous systems a lack of sufficient speed can lead to all kinds of glitches which are typically very hard to explain and debug. I wouldn't at all be surprised if a good deal of the issues Alexander listed are indeed simply due to akonadi agents expecting an "instantaneous" reply but not getting one because too many other agents are expecting the same thing.

R.