init: API

Joe Desbonnet jdesbonnet at gmail.com
Fri Nov 18 00:28:23 UTC 2005


On 11/17/05, Gilboa Davara <gilboada at netvision.net.il> wrote:
Agreed on A+B. C depends on implementation.
There is some truth to D, but I suspect that many simple scripts make
assumptions about the state of the file and can often fail (eg if the
file is hand edited).

There are many benefits: As mentioned earlier, handling international
characters becomes transparent. Schemas can be used to perform
validation. Manipulation by software is potentially much easier. If
there is a standard schema for representing common elements such as
users, permissions, access control lists etc then a standard library
can be written to translate these objects into Python, Java or C++
objects and vice versa.

I'm not necessarily advocating the use of XML. I think it is not
practical to force people to use this (or any other) format if they do
not want to. So instead of stick... some carrot :-)

Pick two or three common formats. Define them precisely (make them an
official standard -- like the Sun/Java JSR idea).  Write an access
library for the most popular application languages (C/C++, Python,
Java etc) and include those libraries in the Core.

In conjunction with this a "best practices" document can make
recommendations on how to best implement configuration files (eg
pointing out things which some people might forget: i18n issues,
time/date issues, handling different config for different machine
states / runlevels), and point out common mistakes.

If you have time, please take a look at /etc/*.conf.  Most files there
key-value pairs grouped into sections. But almost every file has a
slightly different syntax!

Joe.

> A. Hard to read.
> B. Hard to edit using non-XML editors. (vim in my case)
> C. Tends to create needlessly-complex data structures.
> D. While can be accessed using shell scripts, it requires very complex
> and unreadable code.
>
> On the other hand, what does XML offer in return?

Quiet a lot if implemented properly.

>
> Gilboa
>
>
>




More information about the fedora-devel-list mailing list