[Kde-pim] Marketing blocker collection, DEADLINE: 2013-03-10

[Martin Steigerwald]

Am Donnerstag, 7. März 2013 schrieb Andras Mantia:
> Lindsay Mathieson wrote:
> > Aside from that - just how are users going to fix a corrupted or out
> > sync "Cache but not really a cache". Because it has and will happen.
> 
> I still feel confusion here. :) What gets out of sync of what?
> Akonadi db and the original storage? For that we have the syncing.
> Akonadi db and Akonadi config files? Well, we are just working on this
> issue, no?
> 
> I guess I need to write the part2 of my blog:
> 
> http://blogs.kde.org/2011/11/13/akonadi-misconception-1-where-my-data
> 
> As I see the part1 was indeed not that complete regarding what exactly is
> in the database and how it acts (although it is valid what I wrote
> there).

I´d greatly appreciate it, cause reading the thread I get more and more 
confused as to what is where.

Also I agree with Sven that robustness is absolutely critical. I think its 
good to make it difficult for the user to destroy his data. As thus I also 
think that Akonadi shall survive any deletion of the database without any 
data loss on the mails - except for possibly not yet stored mails from the 
write cache of it.

Any possible references from the text file bassed KMail configuration to the 
database shall either break cleanly, so that filter rules just do nothing 
anymore, or somehow be preserved during a database delete and replace 
action.

I am not sure whether I´d cache the mails in the database at all. I always 
thought the maildir like approach for caching mails in extra directory to be 
quite nice. I´d cache the mails as files in the filesystem.

If all of this is not feasible and a deletion of the database cannot be 
supported, then I think its crucial, to provide the users with easy 
solutions to all the cases where they currently use a database removal and 
recreate action to solve issues.

But still, even then I think its crucial to detect such a database 
replacement action, put a BIG FAT warning window on next Akonadi start and 
refuse anything that can do harm to the actual PIM data as mails, calendars 
and such.

A PIM application suite stores *important* data for the users. And I think 
the protection of the data has to go *first*. If the design does not allow 
for it, I think its important to improve the design.

Loosing user data in not easy to understand circumstances for the users, 
i.e. when the user itself did not delete it by her own hands, i.e. did not 
rm -rf the directory with the mails itself or the mails stored on the mail 
server, IMHO is a big fat absolute and top notch marketing blocker.

KMail 1 had some of these issues as well, like the no subject empty body and 
header mails after some index breakage on some circumstances and upon faces 
it I always felt the urge to use something else. Its just that I do have so 
much stuff in KDEPIM that it would be quite some hassle to migrate.

Thus, the original PIM data is authoritative. KDEPIM / Akonadi may not 
delete or destroy it in any way without explicit user consent.

-- 
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/