Re: [Config4gnu-developer] please clarify

[Justin Y. <ju...@sk...>]

Andreas Jellinghaus said:
> Hi,
>
> looking at your project, I have these questions:
> (could be put into your FAQ)

I'll add them shortly, they're good questions  :)

>  - why not GConf?
>    Yes, i want to know in details, very very in deep. And I know that
> gconf is now what you want, but I'd also like to know why starting
> without it is easier as with.
>
>  I'm not related to the gconf project in anyway, have not even used it.

Well, we looked at GConf to an extent, and it does appear to have
potential.  We thought that some of the design considerations made in
GConf were not the best choices that could be made.  GConf is more of a
total replacement for "plain text" configuration files, storing everything
in XML on disk.  This is good for some things, but not all.  There are
other similar reasons as well.  Basically, if we were to work on GConf,
we'd probably want to completely redesign some or all of it, and that
isn't always easy (nor is it necessarily less work), so we decided to just
go at it alone.  That said, we've intentionally made our design very
modular, so that other projects can make use of one or more of our layers
without using the others.


>  - Is part of the design, that applications such as Apache, Samba etc.
>    will kick their own config file formats, parsers, writers and use the
> result of this project as universal replacement?

Part of our design will allow this, but we're not necessarily going to
encourage it.  Another project could potentially use our XML
read/write/edit libraries & tools to store their config natively in XML.

I would much prefer to edit most native config files than something
muddled with XML tags everywhere.  XML's strength is when a program is
doing the modifications, so we decided to convert native config files on
the fly to and from XML as needed, so that the XML is only seen by
applications that *want* to see XML.  Otherwise, apps & users can still
just directly read the native files.

This means that our config-editing UIs will only understand config files
in XML, but the authoritative copy of the configuration stays in the
native format.  You may wonder why we don't just go totally w/ XML and try
to abandon native config files.  The reason is that using our design, its
not necessary.  There are 2 disadvantages to our approach.  First, it
could be a performance problem.  This will be minimized by caching &
dynamic loading, so it should not be noticable in most cases.  Second,
there's the possibility that a user will create an invalid native config
file, causing errors in the conversion to XML.  We'll just have to handle
this as cleanly as possible.

>  - Is part of the project to get your hands dirty and do these changes?

We will be working on adding the supporting files needed to support
various applications, servers, etc.  We would also like project
maintainers to include our supporting files in their packages.  So, yes,
we will be working to support lots of things initially, but after that, we
would prefer if project maintainers were responsible for updating the
files as needed.  This will eliminate version problems.  Since the
supporting files will be updated & installed at the same time as the
actual applications they describe, they will always be up to date.

> c4g isn't the first project about the topic. All other projects i know
> start with new code for some reason, and either straight not change the
> application (only provide a wrapper around the applications config file
> format - yast, webmin, linuxconf etc.) or theoretically allow an
> application to be rewritten using the new library/format/parser/writer,
> but never implement this on their own.
>
> If I understand your documentation correctly, the goal is to create the
> same thing as yast, linuxconf and webmin, but do it better.

We mostly want to create a better webmin/linuxconf system & try to revamp
how projects think about configuration.  Our library will also make it
possible for projects to read their config files through the library,
making it easier for them to parse their configuration, but this isn't
required.  We'll also do validation automatically.  Also, they can invoke
one of our UIs to edit their configuration, so all aspects of
configuration will be *able* to be handled by our system.

Hope this answers your questions.  Jason, do you have anything to add?

Justin


-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com