[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

N-way system (was Re: Offer of help)



> > [regarding a one-way system]
> > > And thats the problem. Thats what realy kills you when using SuSe and
> > > yast as a debian user. Debian should handle it smarter.
> > 
> > I agree completely. But parsers are difficult and a two-way system will
> > take time to be built. In some cases parsers are straightforward and
> > should be provided but in others it is trickier. I think that a one-way
> > system designed to become a two-way system eventually is the right way
> > to proceed.
> 
> 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".
There is a small technical difference: I deal with all variables at the
same time while you deal with them one by one.

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.

Let me point out again that my proposal does not conflict with yours, it just
complements it.

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.

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.

Fernando



Reply to: