[Kde-pim] Does KDE PIM development need focusing?

[Martin Steigerwald]

Am Dienstag, 24. Februar 2015, 23:24:33 schrieb Ingo Klöcker:
> Hi all,

Hi Ingo,

> it's great to see the new enthusiasm for KDE PIM development, e.g. with
> akonadinext.
> 
> Reading the "akonadinext update" thread with its discussion about mail
> filtering and spam filtering I somehow got the feeling that something is
> wrong. That we are maybe trying to solve a problem in the client that
> shouldn't be solved in the client. Yes, some people need client-side
> filtering so we cannot not offer client-side filtering. But we need to
> ask the question whether it's worth implementing a complicated solution
> for those poor souls.
> 
> This made me thing of the "vision" thread (from November last year, but
> I've read it only some days ago) on kde-community.
> 
> So, now I'm asking myself (and you) whether we should focus KDE PIM
> development by targeting a specific group of users for the upcoming
> larger improvements like akonadinext, so that we can more easily make
> decisions. At least, initially. I can name three sufficiently distinct
> groups of users: 
> * corporate users
> ** use central mail server (w/ server-side filtering capabilities and
> centralized virus and spam filtering)
> * private power users
> ** access their mail accounts from multiple machines
> ** often use server-side filtering
> * normal private users
> ** use a single computer for reading their mail
> ** mostly use client-side filtering (or no filtering at all)
> 
> Of course, it's not all that black and white.

From a user´s point of view I see one issue with this:

While I think it can help to get something ready with Akonadinext more 
quickly, I am quite confident that users will expect that their setup will 
work and that they can migrate their data easily. And IMHO rightfully so.

So I think before ditching the old Akonadi the new Akonadinext IMHO needs 
to be feature complete regarding supporting old configuration and the 
migration of data. Please, pretty please do not repeat the migration 
hassle that users had with Akonadi. And Akonadi even still supported 
mixedmaildirs which I am not sure that Akonadinext will do, although I get 
the impressing this support is bitrotting as well. I still have a large 
mixedmaildir directory I did not yet readd into Akonadi based KMail as 
last time I tried it the resource ate the remainder of the 8 GiB I have in 
this laptop and the laptop started swapping like mad (I reported the bug 
back then). So for Akonadi I still do not have all my mails in access with 
KMail.

So before taking away Akonadi from users, please make sure it can handle 
the data and the configuration of at least the majority of current setups. 
I am willing help testing with local maildir and mixedmaildir setups.

I know mixedmaildir is considered a legacy and I wondered whether one can 
make an import that imports all mbox folders in a new archiving mail 
resource and import everything thats maildir in a regular maildir 
resource. Heck, I separated those anyway before the migration to Akonadi. 
I put all archived mails into the mixedmaildir resource which only 
consists of mbox folders and put the rest in a newly created maildir 
resource *before* migrating to Akonadi.

I know it may not be feasible to support all current configuration as is, 
but if there are things that users need to change *before* migrating from 
Akonadi to Akonadinext I think its good to have this documented and let a 
migration check the requirements before it is even started. I am willing 
to help with documenting things like this. I expect really advanced and 
exotic setups like mine are made by users who are used to fiddling things 
around and may not bother too much with *some* manual preparation work for 
the migration. Actually I wonder how many users still use mixedmaildir 
resource. Its the default result of a migration from KMail 1, but I don´t 
know for how many users that migration even work. For me it didn´t really 
give the results I wanted to see and thus I didn´t do the migration with 
the officially supported, but IMHO broken way, but re-setup things with 
clean maildir resource.

I think users have put up with a lot with Akonadi. And I find it unwise to 
upset them once more. I know they have given harsh feedbacks that 
sometimes were just unkind and in a tone thats was not respectful at all. 
But I think users also had a point to make. Akonadi had it faire share of 
issues, and I think many users have been rightfully upset with it. I do 
think Akonadi still have issues, while it for sure is working better than 
at the beginning. I think users are putting up with much, as I think users 
do not like to switch mail clients and address books. At least I have 
grown used to using KDEPIM and thus put up with a lot of troubles. I think 
KDEPIM / Akonadi, besides Nepomuk back then, has been my major bug 
reporting component for that last 5 years.

So I think it may really be good to start with prioritizing the 
implementation, *while* keeping in mind that the majority of the user 
setups and configuration needs to be there before switching the userbase to 
it. I think after defining personas a table can help to determine the 
current features of Akonadi and then which features each persona needs. 
Maybe there are even features so exotic that no one would need them. At 
least not initially. Especially mail is a beast. Just go through the menus 
and various option windows in KMail to see what I mean. I am using quite a 
subset of functionality, but nearly not everyting.

Maybe with Akonadinext I´d look at the code as well, I did browse Akonadi 
code as I did the maildir related performance fix as guided by Sergio and 
Dan – they completely guided me from using kcachegrind, finding the issue 
and fixing it – and I found it difficult to find my way with Akonadi and to 
understand what is where. I think its good to have things modular with 
clean dependency relations. So I like the approach of Akonadinext that 
resources take care after themselves and store their own metadata in the 
way they see fit, instead of storing everything in a large RDBMS centrally. 
At leasts that how I understand it.

I have checked out Akonadinext already. Maybe if I look at it from its 
beginning and maybe even help to document its structure as it evolves, I 
can understand enough to help here and there. I think I would like helping 
with creating some kind of archival mail resource, that archives folders 
as single, maybe even compressed files, to archive mails away from maildir 
resources to reduce file count for backuping, and to archive mails away 
from IMAP accounts to reduce load on the server or just to reduce the 
amount of private data on the server. I.e. like a mixedmaildir resource, 
but *only* with mbox like folders as I think it may really be good to put 
away with mixing maildir and mbox like in mixedmaildir resource, unless a 
clever concept would make it easy and straightforward to implement.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
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/