[Kde-pim] configuration in akonadi-next

Sat Jan 10 13:59:41 GMT 2015

Am Freitag, 9. Januar 2015, 13:18:14 schrieb Christian Mollekopf:
> On Friday 09 January 2015 06.42:35 Pablo Sanchez wrote:
> > [ Comments below, in-line ]
> > 
> > On 01/09/2015 03:14 AM, Aaron J. Seigo wrote:
> > > To be honest with you, I'm not overly concerned about text vs binary
> > > config
> > > file formats. It's a somewhat minor issue. I am, however, concerned
> > > about
> > > the project's ability to make decisions based on actual needs driven by
> > > actual user practice, and that's a way I'm trying (evidently without
> > > success ;) to encourage people to approach these kinds of topics.
> > 
> > If the above is the case, then let's leave the config file(s) as human
> > readable text files.  This means adding useful comments and mnemonic
> > parameter names.
> > 
> > Software has /moving parts/ and if a config file is one which I can fix
> > out in the /field/ (not submit a bug, open up a hex editor), then make
> > it easy for us end users.
> 
> I don't think we're in a position to make those decisions right now.
> 
> There clearly are advantages to both approaches, and I'm pretty sure there
> isn't an argument which allows us to generally rule out one or the other
> approach.
> 
> I fully agree with Aaron that the current configuration mechanism is
> somewhat of a mess at times, and I do think we will need to address this at
> some point in one way or another, but I'm also a friend of simple,
> introspectable and predictable systems (which can mean text config files
> where it makes sense).

Wonderful. I like that and it reminds me to read all replies before I reply, 
admittedly a bit heatedly.

I really like software to be transparent and user accessible. Don´t hide how 
it works from your users. (Sure in free software you can always lookup the 
source, but I bet you know how I mean it.)

> For akonadi-next and kaccounts we need to list actual requirements and then
> come up with a suitable mechanism, and not define a mechanism and then try
> to hammer our requirements into that mechanism.
> 
> We have a variety of different configurations that will likely require
> different mechanisms anyways.
> 
> Here's a short list of types that I can think of:
> * Domain specific configurations (calendar colors, tag colors, email folder
> settings, Folder subscriptions, ...)
> * Account/Service configurations (IMAP, LDAP, ..., Identities, passwords?)
> * Local configurations (window size, selections, ...)
> 
> Domain specific configurations should end up in the akonadi domain model,
> allowing the backend to synchronize the data. This is essential to provide
> an integrated system that can deal with more than one device (which is
> largely the point of akonadi). These configurations should probably be
> editable through an application UI, and be stored in akonadi directly.
> 
> Account configurations provide the means to access the service and will
> probably end up being a mix of local configurations (what services do I want
> to use on that machine), and service provided configurations (what's the
> ldap server going with my kolab account). So this may involve local ini
> files or a sqllite database or ... plus information pulled from akonadi and
> autoconf or similar.
> 
> Local configuration may be stored entirely on local disk only, although the
> better the integration, the more information may move to domain specific
> configuration. The window size probably doesn't make much sense to sync, the
> list of selected calendars to show probably does. And the last visited mail
> folder just might as well.
> 
> So yes, we may continue to use local ini files for certain parts, but for
> others they just don't cut it IMO. Where we draw that line is up to us.

Okay, that sounds quite a bit different. I see that there are stuff in the 
configuration files like kmail2rc

[MessageListView::Aggregations]
Count=10
Set0=0000cafe000010020000001800310[… a lot more of this in a big huge blob]

that doesn´t seem make sense to have in there.

Or this:

[MessageListView::StorageModelSelectedMessages]
MessageUniqueIdForStorageModel10=521873
MessageUniqueIdForStorageModel100=734751
MessageUniqueIdForStorageModel101=1034884
MessageUniqueIdForStorageModel102=604851
MessageUniqueIdForStorageModel103=1144777
[…]

is probably not that useful for manual editing as well.

That said in kmailrc (pre-Akonadi KMail) I don´t see these.

I suggest also to differentiate between

1. configuration
2. state

I probably would not stuff both into the same file. In the sense that I don´t 
consider which folders in the tree view are currently open as part of the 
configuration. In a broad sense it is, but I´d differentiate between the 
configuration where the user has to set a setting and to press "save" 
afterwards and just the state that changes while the user is regularily using 
the application.

So I agree that a careful review of the needed configuration and what does 
where makes sense. But I disagree with some "make it all binary and then all 
is good" approach. Let the requirements define the best way to store things.

Additionally I would like to see Akonadi become more robust in case of a 
database failure. I think as Akonadi next doesn´t necessarily use a 
traditional database that may be addressed already, but I never liked what I 
see to happen when I loose the MySQL database for Akonadi, having it go 
corrupt for some reason. After recreating DB from scratch filters and 
identities and so on point to wrong folders and so on. I would like to see 
Akonadi really just act as a cache here. If I delete it, its recreated, and 
thats about it. So I dislike if actual configuration depends on the state of 
the cache. I think this is quite broken in terms of crash resiliency and 
recoverability.

That I may loose some tags and so on, well, okay. But filter settings?

Maybe Akonadi could mark locally stored folders with an ID in a xattr and IMAP 
based ones with some ID on the server to rediscover them after local cache 
loss. Maybe there are different approaches, but I´d really like to see Akonadi 
next be more robust in that area, as in: Never loose user data from cache 
corruption to the maximum extent possible.

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