[Kde-pim] configuration in akonadi-next

[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).

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.

Cheers,
Christian



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