Le mardi 05 décembre 2006 à 16:30 +0100, Nicolas Mailhot a écrit :
> Le Mar 5 décembre 2006 14:39, Mark McLoughlin a écrit :
>
> > Take a look at the how the XML files are saved these days (they're
> > indented)
>
> Good, the situation is slowly improving then.
…
> Now I think I've looked at the rawhide gconf evo files in the last two
> months, and they were the mess I remembered,
Since I've sinned by talking from memory, and from memory of a known
gconf abuser, here is a quick sysadmin-oriented review of the latest
gconf files I have access to (rawhide system)
1. the file hierarchy is weird. The default file is named "%gconf.xml",
which seems to protect against inexistent collision risks (gconf seems
to only allow those files or directories, so anything ended in .xml
would have fit the bill)
2. I can understand the choice to only allow foo/%gconf.xml instead of
foo.xml files (leaf vs parent node safety), but only because of my
background. Most humans will find this choice weird, unintuitive and
heavy-handed on directories
3. all the conf files I've skimmed only use XML nesting for technical
not functional reasons, they don't even have the first level of grouping
of .ini files, so one wonders if the XML potential is really used there
(esp. WRT the deep filesystem directory nesting used at the same time)¹
4. OTOH the format is needlessly nesting and verbose for technical
reasons. A sample (composition of gconf extracts):
<?xml version="1.0"?>
<gconf>
<entry name="draw_background" mtime="1141418301" type="bool" value="true">
</entry>
<entry name="picture_filename" mtime="1161888920" type="string">
<stringvalue>/usr/share/backgrounds/images/default-wide.jpg</stringvalue>
</entry>
<entry name="applet_id_list" mtime="1163807026" type="list" ltype="string">
<li type="string">
<stringvalue>systray</stringvalue>
</li>
<li type="string">
<stringvalue>trash_applet</stringvalue>
</li>
</entry>
</gconf>
a. what the hell is mtime doing there? If the gconf users are not live,
why should they care when an entry was modified ? If one or several
users are live and you need to track concurrent modifications, surely
this can happen in a memory cache without ever hitting the file system ?
This bit alone prevents safe manual editing
b. why is the typing in the conf file itself and not in a separate file?
(that could be written using a standard syntax like Relax NG generic
tools like vim or xsltproc have a chance to understand)
c. the boolean entry needlessly uses two lines
d. for the following entry: now we've written the entry is a string
(which tells us nothing, string basically means untyped) instead of
filling it with an xml string directly, someone though it was smart to
stuff the xml string in a <stringvalue> element. Why the heck for ? I
could understand it if you could have several stringvalue children, but
multivalued elements 1. have another type² 2. wrap their stringvalues in
li elements anyway.
Put all those remarks together and you could have :
<?xml version="1.0"?>
<gconf xmlns="typing-schema-id">
<!-- Have GNOME draw the desktop background -->
<entry name="draw_background" value="true"/>
<!-- File to use for the background image -->
<entry name="picture_filename">/usr/share/backgrounds/images/default-wide.jpg</entry>
<!-- A list of panel applet IDs.
Each ID identifies an individual panel applet.
The settings for each of these applets are
stored in /apps/panel/applets/$(id) -->
<entry name="applet_id_list">
<li>systray</li>
<li>trash_applet</li>
</entry>
</gconf>
typing-schema-id being the id of a schema properly declared in /etc/xml
for vim, libxslt and friends
I don't think this variant would be any more difficult for apps. For
humans it would definitively be nicer.
¹ ignoring the schema part for – IMHO it could safely be moved
to /usr/share as it's not were configuration takes place.
² I won't expand on the type + ltype + type-in-li thing
--
Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
