[Kde-pim] configuration in akonadi-next

Fri Jan 9 08:14:00 GMT 2015

On Thursday, January 8, 2015 21.23:44 Ingo Klöcker wrote:
> I'm reluctant to warm up this old thread, but so far you didn't give any
> good arguments for not using text files for configuration. OTOH, we listed
> several arguments in favor of text files.

I attempt to clarify what I've been trying to communicate below.

> On Friday 19 December 2014 19:58:05 Aaron J. Seigo wrote:
> > On Friday, December 19, 2014 19.19:13 you wrote:
> > Even with Kontact and Akonadi's configuration in text format, it still
> > absolutely sucks for trying to find the right config data. Having a
> > command
> > line tool that automates that for people would be lovely.
> 
> You mean like our lovely kreadconfig and kwriteconfig? They work nicely for
> KDE's (text) config files, don't they?

They make interacting with files easy if:

a) you know which files your data is in
b) you know the group names
c) you know the key names
d) the files don't do funky things like use binary data, internal / hard-coded 
magic values, etc.

What I was thinking of was not an easier text editor, which is really what 
k[read|write]config are (nicer to use from scripts and hides some 
implementation details, but little more), but tools which make it "fool-proof" 
to do actually required tasks like:

* bundle up all the relevant config (properly sanitized) necessary to 
troubleshoot various classes of user problems (bugs for developers;  
configuration issues for tech support)
* isolate specific configurations for removal, replication and/or backup
etc...

k[read|write]config are entirely unuseful for this when it comes to Kontact / 
Akonadi, even though they store their configuration in plain text files. 
Realizing that "it's text!!!!111!!" is therefore not sufficient to come to the 
conclusion that the configuration system is good or even useful.

> And, IMO, this proves a strong point against any specialized tools, the
> point being that for configuration stored in text files one doesn't need a
> specialized tool. Any text editor works fine for any configuration file in
> /etc.

This is true for:

* trivial text files (storing binary data structures or strings generated from 
internal run-time data structures are not that)
* text files which the user knows the location of, the structure of and the 
allowed contents of

The latter can be resolved by documentation for people willing to put in the 
time. But who is going to put in that sort of time to deal with Kontact 
configuration files? Users generally require tools that make short work of 
tasks in humane ways. It is why we create GUIs in the first place.

Kontact users would be much, much better serviced by a set of tools that 
manage Kontact and Akonadi's (necessarily!) complex configuration data.

Stating "but they are text files" and "text files can be edited with text 
editors" does not in any way make the configuration something that users can 
usefully manage or interact with.

> Of course, it's nice to have a special end-user configuration tool, but that
> doesn't mean everybody has to use this tool.

Let me post you quandry, then:

If an end-user tool was required to make it usable for 98%+ of users, but the 
most sensible way of providing that tool was to not use plain text files for 
configuration, would you insist on text files for the 2% at the expense of the 
98% of users? ... and what if those 2% happen to also be technically savvy 
enough to get around such trivial matters such as "the file is not plain 
text"?

Who, exactly, are we optimizing for?

> > It isn't enough to just say "they are text files, text files are good,
> > therefore we are in a good place". It just isn't so.
> 
> And I say "It is so.". ;-)

I've already demonstrated in previous emails how the data in Kontact / Akonadi 
configuration files are entirely opaque to just about everyone who isn't a 
Kontact / Akonadi developer. Instead of saying "It is so", please address 
that.

> For binary-format config files you always need a special tool. For

Well, a hex editor is not a "special" tool. but if there is no real world, 
actual benefit derived in actual practice, it doesn't matter (theory is worth 
zero). so how many of our users edit their config files with a text editor? 
for those that do so: why do they do so? is that their first choice, or would 
they be better served by other means? 

The choice to have scattered text files without metadata or tools to manage 
them outside of "end user" config UIs (which in practice don't touch all parts 
of the configuration data set) comes with costs related to manageability. KDE 
software still does not have a good way to replicate configuration from a 
central store typical for large scale user and group management and that is in 
part due to the choice of insisting on spread-around, metadata-less, text-only 
files.

Those costs must be justified by commensurate gains from sticking to "the way 
it's always been done", otherwise theory is making the software worse than it 
needs to be in practice.

.. and yet KDE developers continue to wander around saying, quite 
irrelevantly, that "it's all text files, what could be better?" The focus is 
really on the wrong place, and it leads to really unhelpful ideas like 
"special tools are bad", something that was said in this very thread.

> text-format config files you do not necessarily need a special tool. In my
> book, that's _the_ argument for text and against binary config files.

If the goal was simply to allow editing config files that would be compelling. 
But config files are a means to an end, not an end to themselves; choices in 
configuration have large impacts elsewhere in the product.

I can come up with reasons for using text files, but not one of them is "you 
can open them in a text editor" because that does not describe a user benefit. 
Things like this are more interesting -> "virtually all extant revision 
control systems operate on text files far better than they do on binary files, 
so this makes revisioning easier" (though that it made almost irrelevant with 
modern snapshot based filesystems). Or a theoretical "configuration 
distribution system $X expects/requires files in text format $FOO" would be 
quite compelling.

Making decisions based on observations such as "can be opened in a text 
editor" (irrelevant because it "never" occurs and is the best solution to 
precisely zero real world problems) is dangerous for the future of the product 
as it is not user-benefit focused and indeed prevents the exploration of ideas 
with may well serve the end-user better.

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.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20150109/6d4488e5/attachment.sig>
-------------- next part --------------
_______________________________________________
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/