Re: Offer of help
> What exactly should the templates be for? Configuration?
Yes. The idea is that all configuration files which need system-specific
data be generated from templates which hold the non-specific part and
from specific data residing in a database.
> Who should ever lern the syntax or correct scripts if something is wrong?
See below.
> What happens if you parser doesn't work? Can you still install
> packages?
If a configuration file is not properly generated the package will install
but it may not work as intended. In that case, the config file will have to
be manually corrected. In this respect, nothing changes essentially from
the current situation.
> Can templates be localised? Do you get localised help to templates?
Yes. Templates in different languages can be provided if it is necessary.
The most important part is providing help/description of variables in the
database in local languages. I think this can be accomplished in one of
two ways:
1) A multilingual database is provided:
Name: variable1
Desc: Default description in English
Desc_es: .... (spanish)
Desc_fr: .... (french)
Desc_de: .... (german)
Then the user interface chooses the Desc_xx: field to be used according to
user preferences and availability. (I did not implement a user interface.)
2) Overlays are provided with the Desc: field in the localized language.
An overlay contains only two fields per variable:
Name: name of variable
Desc: localized description
My generator includes functions to merge the overlay with the main database.
> Your templates look pretty difficult to understand and pretty messy to
> me. Normaly maintainers can program c (or whatever their program is
> written in) and bash (enough for the postinst script). Why force them
> to learn a rather difficult and messy language like yours?
OK. This may be my fault because I tried to communicate too many things
in too few words. I tried to show how powerful it could eventually be
instead of showing how simple it usually is.
First of all, any system will have a learning curve. Even if it is written
in bash or C, that will not be enough to make it easy. Maintainers will have to
learn a new API, new shell commands and new options to those commands. That
is no different (and sometimes even worse) than learning a new simple
purpose-oriented language with a straightforward syntax.
Second, but most important, from the point of view of maintainers there are
essentially only three commands to learn for writing a template:
1) \sysvar: You write this whenever you want a value to be looked up in the
database.
2) \systable: Similar to 1), but it looks up an entire table instead of a
single variable.
3) \if: Conditionally generate a block based on the value of a variable.
All the rest will have to be understood only by admintool developers. The
system automatically asks the user for values when a variable is not found
in the database. No maintainer action is needed.
Third, my system can call external programs, so C and bash are still available
to maintainers.
> I can't see any benefits over my proposal, which probably covers your
> ideas and much more. My config scripts would be valid bash scripts
> with only a few limitations to allow for better parsing.
Any system has advantages and disadvantages. I am not going to get into
a "my system is better than yours" flamewar. I did look at your proposal and
found it interesting. I also looked at Wichert's proposal and most others
that have appeared in this list.
Regarding your proposal, I think it is mostly orthogonal with mine. They
overlap very little. The kernel-config style system is a good way to gather
all answers from the user at install time and populate the database. It deals
mainly with the front end: how to interact with the user. Once the database
is filled, then we have to deal with the back end: how to generate the config
files from the values in the database. This is where my system fits. It
provides an alternative to writing shell scripts. Why not shell scripts?
These are my reasons:
1) Templates are a more natural way to deal with mostly static text. This
is the usual case in a config file, where the data dependent parts are
usually small. It requires less programing, even though my example suggested
otherwise. (It was a bad example, as I realized later.)
2) The built-in table processing makes generating tables a non-programming
task. Most config files have tables, so maintainers will save lines of
coding.
3) The built-in database engine allows a clear separation between the data and
the format.
4) The built-in infinitely recursive engine allows users to redirect querys
without touching any script. It allows complex settings to be encapsulated
in a single variable.
Besides, all this is provided as a library, so it can be used in C programs
and shell scripts too.
> Also you will get problems when people change the config files
> directly instead of using the database. Those inconsistency give the
> users hell on earth. You eigther can't use the database at all any
> longer, because on every run it will destroy all your changes or you
> can't use it, because it won't work on user modified configfiles.
Any one-way database based system has this limitation. That is why I proposed
the inclusion of parsers two years ago and that is why I still hope to get to
that part some day. But a one-way system can still have advantages for many
users.
> Also you can't create a database from a running system, e.g. for a
> backup, or suggest whatever was selected last or by the package when
> asking question. You make no differencing between values specific for
> some architecture, only one host or all systems. Also you don't have
> levels of questions, allowing to skip many when beeing an
> unexpirienced user.
I do make all those differences. It seems that my example was too complicated
in one sense and too simple in another. Anyway, all these are implementation
details which can be accomplished with my system.
My program is a general purpose macro processor. No specific data is hardcoded
in it. Any database design (I mean: name, number and purpose of each field)
can be accomodated. That is the main purpose of this list, as I understand it.
Designing which fields the database will have and for which purpose they will
be used.
Thanks,
Fernando
Reply to: