On Tue, 2003-02-18 at 20:28, Tom Eastep wrote:
> I have been watching the progress of the new LEAF configuration
> mechanism with some interest and while I haven't had the time to follow
> the various threads closely, I have formed some impressions and I have
> some concerns.
>
> From what I understand, the new configuration system relies heavily on
> (attribute,value) pairs. The idea seems to be to define these pairs
> centrally and then propagate them into the various packages using some
> sort of configuration API.
I wouldn't worry. The config-db that Lynn, Eric and I are working on is
actually based on a filesystem hierarchy. It is basically like a big
perl nested hash, with the ability to nest arrays as well. It is
actually working out pretty well. It can be accessed with full paths or
relative paths.
It can generate and be fed with name=value pairs, but that is where the
nvp paradigm ends. The most recent code is in my cvs repository at
devel/ccarr/devel/leaf-tools/cdb
Take a look and see what you think. The documentation for cdb is
devel/ccarr/devel/leaf-tools/cdb.help
It is pretty close to complete. The test harness is in
devel/ccarr/devel/leaf-tools/test-cdb.sh
That will give some examples of different ways to use it, as well.
> The bottom line is that (attribute,value) configuration is much less
> flexible than the table-oriented configuration technique supported by
> Shorewall and by reducing Shorewall configuration to (attribute,value)
> pairs, you confine yourself to a very limited set of firewall
> applications. When users outgrow that limited set, they must undergo a
> paradigm shift and use a totally different configuration method.
I think that the current filesystem hierarchy method will be able to
represent any information currently in any of your files (carrying with
it even more symbolic information than in a columnar table
representation). Since the goal is to be able to configure shorewall
and other applications, if we cannot ultimately represent everything in
your configuration files, we have failed. Please let me know if you
have any other fears when you see the implementation.
> As I said at the outset, these impressions/concerns are formed from an
> understanding of the current proposals that is far from complete.
> Corrections and criticisms are welcome...
Your input and code review is _greatly_ appreciated. As I said before,
your code is extraordinarily well written and I have learned a lot about
/bin/sh from reading it. If you find a construct in your configuration
that you feel cannot be represented by this method, I will be happy to
take a look at it and modify cdb if necessary.
--
-----------------------------------------------------------------------
Chad Carr [EMAIL PROTECTED]
-----------------------------------------------------------------------
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
