Fernando <[EMAIL PROTECTED]> writes:
> > My approach was that by default a database via shell scripts
> > (var="value") would be used. If that doesnt suit the package, he can
> > proide get_var and set_var programs/scripts to interact with the configfile
> > or database. If you only provide set_var you would have a one_way
> > system like yours. But once you have set_var, writeing get_var is
> > trivial and set_var you allways need, so why not make a two way system
> > anyway.
>
> AFIW your "get_var" is my "parser" and your "set_var" is my "generator".
get_var and set_var are the interfaces to the database. They don't
know about type or contents of a variable, they just know how to store
it to the packages conffile or read from it.
> There is a small technical difference: I deal with all variables at the
> same time while you deal with them one by one.
Your parser or template generator could also use set_var/get_var to
actually access the database. Its not the same as your parser/template
generator but a level below that. They both build the database and
normaly they would use the package's own conffile as database to
circumvent differences between database and conffile.
> I have not come with a good solution for the parser/get_var yet, although I
> think it will have to be something similar to the solution I am proposing
> for the generator/set_var.
>
> In summary, my proposal for the generator/set_var is that instead of having
> to write a program for each config file you just write a template. Templates
> should be trivial to write in most cases because they are just the config
> file with the actual data substuted by database calls. So, instead of
>
> variable=value
>
> you write:
>
> variable=\variable (lookup_in_database)
>
> and that's all you need to do in general. The general case is slightly more
> complicated than that, but still easier than what you would have to do if you
> had to write a whole generator/set_var from scratch.
Most programs have a more complicated conffile and then the templates
get realy ugly and without the ability to extract variables from an
existing or user modified conffile the tool is worthless, it would do
more harm than good. So you need a get_var interface anyway (which
could be template generated :) and a set_var is then trivial (which
could also be template generated).
> For the parser/get_var part, having to write a program for each config file
> is a tedious and difficult task to ask to all maintainers. What I am thinking
> of doing is a grammar-driven parser. However, it does not need to be as
> general as lex/yacc because config files usually have a straightforward
> grammar. In any case, I will not write this part until I finish the generator.
Anything short of lex/yacc parsing will be insufficient at some
time. I don't think restricting the syntax of conffiles below lex/yacc
level would be good.
> You seem to believe that the difficulty involved in writing get_var is the
> same as in writing set_var. However, this is far from being true. The
> complexity of get_var is much much higher than that of set_var. That is why
> two-way systems are so rare.
The few get_var/set_var functions I've written for testing purposes of
my proposal seem to be very similar. If you have one of them done, the
other one is easy. Actually writing set_var seems more difficult,
since you have to try to keep alignment and extra spaces in place to
keep the conffiles nice looking and you have to insert variables at
the right places, which get_var goes along wiht some greps and cuts.
If get_var is a problem to write, one can allways just copy the parts
from the source that read the conffile.
May the Source be with you.
Goswin
