--===============7125836540935900322==
Content-Type: multipart/signed; boundary="nextPart1622655.33zTzAqvxP"; micalg="pgp-sha1"; protocol="application/pgp-signature"


--nextPart1622655.33zTzAqvxP
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Thursday, January 8, 2015 21.23:44 Ingo Kl=F6cker 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 l=
isted
> 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 st=
ill
> > absolutely sucks for trying to find the right config data. Having a=

> > command
> > line tool that automates that for people would be lovely.
>=20
> You mean like our lovely kreadconfig and kwriteconfig? They work nice=
ly 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 / har=
d-coded=20
magic values, etc.

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

* bundle up all the relevant config (properly sanitized) necessary to=20=

troubleshoot various classes of user problems (bugs for developers; =20=

configuration issues for tech support)
* isolate specific configurations for removal, replication and/or backu=
p
etc...

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

> And, IMO, this proves a strong point against any specialized tools, t=
he
> point being that for configuration stored in text files one doesn't n=
eed a
> specialized tool. Any text editor works fine for any configuration fi=
le in
> /etc.

This is true for:

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

The latter can be resolved by documentation for people willing to put i=
n the=20
time. But who is going to put in that sort of time to deal with Kontact=
=20
configuration files? Users generally require tools that make short work=
 of=20
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 tha=
t=20
manage Kontact and Akonadi's (necessarily!) complex configuration data.=


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

> Of course, it's nice to have a special end-user configuration tool, b=
ut 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, b=
ut the=20
most sensible way of providing that tool was to not use plain text file=
s for=20
configuration, would you insist on text files for the 2% at the expense=
 of the=20
98% of users? ... and what if those 2% happen to also be technically sa=
vvy=20
enough to get around such trivial matters such as "the file is not plai=
n=20
text"?

Who, exactly, are we optimizing for?

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

I've already demonstrated in previous emails how the data in Kontact / =
Akonadi=20
configuration files are entirely opaque to just about everyone who isn'=
t a=20
Kontact / Akonadi developer. Instead of saying "It is so", please addre=
ss=20
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 wor=
ld,=20
actual benefit derived in actual practice, it doesn't matter (theory is=
 worth=20
zero). so how many of our users edit their config files with a text edi=
tor?=20
for those that do so: why do they do so? is that their first choice, or=
 would=20
they be better served by other means?=20

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

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

.. and yet KDE developers continue to wander around saying, quite=20
irrelevantly, that "it's all text files, what could be better?" The foc=
us is=20
really on the wrong place, and it leads to really unhelpful ideas like=20=

"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 comp=
elling.=20
But config files are a means to an end, not an end to themselves; choic=
es in=20
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=20
can open them in a text editor" because that does not describe a user b=
enefit.=20
Things like this are more interesting -> "virtually all extant revision=
=20
control systems operate on text files far better than they do on binary=
 files,=20
so this makes revisioning easier" (though that it made almost irrelevan=
t with=20
modern snapshot based filesystems). Or a theoretical "configuration=20
distribution system $X expects/requires files in text format $FOO" woul=
d be=20
quite compelling.

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

To be honest with you, I'm not overly concerned about text vs binary co=
nfig=20
file formats. It's a somewhat minor issue. I am, however, concerned abo=
ut the=20
project's ability to make decisions based on actual needs driven by act=
ual=20
user practice, and that's a way I'm trying (evidently without success ;=
) to=20
encourage people to approach these kinds of topics.

=2D-=20
Aaron J. Seigo
--nextPart1622655.33zTzAqvxP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEABECAAYFAlSvjcwACgkQ1rcusafx20PJeACfScqDKRrLsIhJYKpIPMG9oSv0
UlIAn0pRnrVRIN2f+cbWZEzCc4LKdgq+
=CuMN
-----END PGP SIGNATURE-----

--nextPart1622655.33zTzAqvxP--


--===============7125836540935900322==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
--===============7125836540935900322==--