Re: N-way system (was Re: Offer of help)
Fernando <alegre@superlink.net> writes:
> > > 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.
>
> No, they are not interfaces to the database because in your model there is
> no database. You say that you use the config files as a database. However,
> that is not a real database because it lacks the two most basic features
> of a database: fields and indexing. The set of config files is a given dataset
> with no freedom at all to introduce new variables or to group them in any
> way we might find suitable. There is no logical coherence between the data
> and no common format. Any tool that mainipulates the dataset must be an
> "ad hoc" tool specifically constructed for each file in the dataset.
get_var and set_var build the interface to a virtual database. Any
tool that manipulates the database must go through those. The database
will be virtual and will be stored in each packages configfile but its
still a database. For backup and restore functions all variables will
be stored in a single file or on a full database server, the only
thing different from stuff like adabas is that the function of the
database are so few.
> What get_var and set_var really are is translators. They translate the
> "ad hoc" format of a config file to a format ready for consumption by bash
> scripts and vice versa. This translation is what is called parsing/generating,
> depending on the direction of the translation.
Thats also true, but thats hidden for the user. get_var and set_var
translate the packages own storage format into something the virtual
databse needs for its interface.
>...
> I disagree about the worthlessness of templates. In many cases, you do not
> want to keep your old values. For example, if you change your domain name,
> you want all references to your old domain name to change to your new domain
> name without having to change them one by one. You might not event know in how
> many config files they appear. That's something that templates solve trivially.
Nothing to do with templates. Any package that needs the domainname
would have to use NETWORK_domainname. If that is changed, all packages
using it will get the new value.
>...
> About set_var being more difficult, I find it surprising. Using templates,
> set_var is usually trivial. All the alignment and extra spaces is just
> copied from the template with 0 effort from the developer.
And no respect for the stuff the user changed. Maybe the user has
added additional comments or changed the indentation of
comments. Respecting this is what makes set_var a bit more difficult,
but its possible with a two way system and is has to be that way.
> > If get_var is a problem to write, one can allways just copy the parts
> > from the source that read the conffile.
>
> Ugh. _That_ is ugly. You know that copy+paste almost never works. A lot,
> really a lot of massaging is necessary to adapt the code. That might be
> asking too much to maintainers.
The maintainer knows his code, or should, if he can't figure out how
to write a get_var and set_var, he should think about changing his
configfile format. Most unix programs have a pretty simple conffile
format, seen as LALR grammar. I will write a set_var and get_var
template that uses such a grammar to set and extract variables, the
maintainer than just needs to fill in the grammar and of he goes.
May be that can even be done without the need of recompilation,
putting the grammar inside the control.tar.gz might be enough.
May the Source be with you.
Goswin
Reply to: