From kde-core-devel  Tue Dec 07 18:16:49 2004
From: Aaron Seigo <aseigo () kde ! org>
Date: Tue, 07 Dec 2004 18:16:49 +0000
To: kde-core-devel
Subject: Re: XML/XSD based configuration files.
Message-Id: <200412071116.53967.aseigo () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110244347629795
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1274063.2zxYhV2gPx"

--nextPart1274063.2zxYhV2gPx
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On December 7, 2004 9:49, George Staikos wrote:
> On Tuesday 07 December 2004 11:45, Frans Englich wrote:
> > On Tuesday 07 December 2004 14:47, Waldo Bastian wrote:
> > > From the buzzword-department.
> > >
> > > See http://bugs.kde.org/show_bug.cgi?id=3D94611

there are a few separate issues here:

0) default configuration file format

besides speed gained by the simplicity of the .ini format, it's a very huma=
n=20
friendly format. people can easily find and change settings as needed. XML =
is=20
not nearly as human friendly, and i think that's an important thing to keep=
=20
in mind as well.=20

1) multiple backends

cool idea, esp useful for configurations that live on the network. i think =
the=20
XML backend is of limited use compared to a DB based backed, but the big=20
issue here will be migrating between back ends, which is where this could b=
e=20
important:

2) configuration server

this was brought up, and while i think it's probably a good idea i really j=
ust=20
hope that it is self-maintaining, by which i mean that whenever its needed=
=20
it's loaded. the biggest problem with configuration servers is making sure=
=20
they are running when needed, especially when the application is run outsid=
e=20
of its native desktop.

beyond that, having a config server would make moving between formats=20
(including things like client-side caching into .ini's of network'd configs=
=20
(think LDAP or RDBMS)) possible without being a nightmare.

3) application data storage

if you read the linked bug report, the person is actually talking about=20
application DATA, not really configuration. look at the set of the files th=
ey=20
use as examples: all live in $KDEHOME/share/apps

xml does make sense for a lot of situations, but outside of very simple usa=
ge=20
it's a PITA to work with programmatically and opaque for users to deal with=
=2E=20
how many people here hand-hack .ui files? there's very few, and it's at lea=
st=20
in part because it's XML which is not a very human friendly format.

that said, it would be very nice to have something for KDE4 that makes=20
programmatic access of xml from kde apps pleasant and encourage usage of th=
at=20
for data storage where appropriate, similar (though not exactly the same) a=
s=20
we do with KConfig for configuration files and iconthemes for icons.

=2D-=20
Aaron J. Seigo
Society is Geometric

--nextPart1274063.2zxYhV2gPx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBtfOV1rcusafx20MRAgUPAKCha5R7qOVWuv4eMglsxbkek+VCewCgsVz1
2rHwOHZHip70ia+tYAb9EBE=
=4Yfo
-----END PGP SIGNATURE-----

--nextPart1274063.2zxYhV2gPx--