Re: dcfgtool and clones
On Mon, 26 May 1997, David Frey wrote:
> Hello everybody,
>
> On Sat, May 24 1997 11:40 +0200 Andreas Jellinghaus writes:
> > there are three tools : cfgtool (lars wirzenius), nod (winfried
> > truemper), dcfgtool (mine). and someone is working on a _real_ tool (all
> > three have flaws, and if this way we will get a tool with all good
> > features).
>
> With somebody, you meant eventually me, since I asked at the Linux-Kongress
> in Wuerzbuerg whether I may upload a dcfgtool clone.
> But whether it's a ``real'' tool, is not so sure... . Don't hold your breath.
>
> > as you can see, it's a small text database. so it has nothing, absolutly
> > nothing to do with deity - that's a GUI.
> agreed.
We are planning on expanding the scope of deity to include a few more
features than "just a GUI" after the initial release though. Including
getting a decent library set together for other developers to use. Making
the config-tool part of this would seem pretty logical.
> > then we should :
> > a) choose _one_ cfgtool (the current one have big flaws. the new one
> > will not have them).
> > b) change policy to _not_ allow config information in /etc scripts
I really don't like this, and I think several others don't either.
> > c) change policy to _not_ allow additional debian uniq config files to
> > fix b). only the textdb should be used.
Definitely. But we have to remain backwards-compatible, so we must be able
to *read*, e.g. /etc/mailname, to be able to convert to the db.
> > d) think about getting rid of some config files only used by shell
> > scripts, and use the textdb instead.
> yes.
>
> Lars Wirzenius <liw@iki.fi> said:
> > Assuming the syntax is simple, and there's no need for complexity, a
> > hand-written parser can be lightning fast, and all the time is spent
> > in starting the program, and reading the file.
> Mine is currently a lex parser and a yacc scanner.
Do you do any hashing? I usually use gperf to generate a hashing function
for the main keywords. This really does give some nice speed improvements.
However, if the format is even simpler than this (no keywords, just
"variable assignments", and comments), it would be faster to use a yacc
parser, and write your own (simpler) lexer. The regular-expression
capability of lex does hit the performance slightly unless you really need
it. GNU flex doesn't suffer from this problem nearly as much as the
original lex did, though - it was severely slow.
> Tom Lees <tom@lpsg.demon.co.uk> said:
> > I know all this. But when will it be finished? What about beta
> > versions? Is there a mailing list (other than debian-admintool)?
>
> Finished in about a week (beta version).
Great! Are you planning on uploading it to experimental or unstable? I
would suggest you upload it to experimental, as it has the possibility to
severely corrupt people's systems. OTOH, you could also put it in your
home on master, as a pre-beta to check if everyone likes it.
> Mailing list other than debian-admintool: no
Maybe we should start *using* debian-admintool then :)
> Tom Lees <tom@lpsg.demon.co.uk> said:
> > It would be really cool if we upgraded the packaging system to handle
> > configuration integrally (so we can do configuration _BEFORE_ an
> > installation, etc.).
> Yes. But the tricky part is how to rewrite all the /etc/hosts, /etc/networks,
> /etc/uucp/{sys,dial,port,config}, /etc/fstab, /etc/slip.dip etc. files.
> I don't have an idea.
How about we do it like apache does its modules? (This might get tricky,
as I'm not sure all developers can program). So the config tool loads all
the modules (using libdl), and then it can use special functions in these
modules to handle these file-formats. OTOH, there aren't that many files
with non-generic syntax... maybe we could simply include separate parsers
for each of these.
> > Deity definitely _IS_ the right place for this -
> > a GUI to do the configuration with, at the same time as packaging
> > control!
> I'd prefer a back-end and deity would be the frontend.
The way I envisaged it was that Deity would get all the configuration
info, and then pass it on to the back-end after it had all the info.
I think the cfgtool should probably be available as a shared lib so that
deity can also read stuff etc., without too much of a slowdown from
execing another prog.
> Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> said:
> > To allow a GUI to present a usefull view of the config file
> > information about each field would have to be known. A short
> > description, it's content type, possible range information, etc.
>
> You can store a comment (a la dcfgtool), but the other things are not here.
> dtxtdb knows about booleans, ints, floats and strings. That's it.
I suggest another two types (although they are really special cases) - IP
address, and FQDN. The regular expressions to handle these really are too
long for something that will be in common use.
My one (in perl) can handle perl expressions to validate types... and IIRC
there is a libperl you can link with to do this. OTOH, we could use GNU rx
or regex to validate using simple regular expressions. Simpler things
could be used tho, like for ints, a "range", etc.
> Andreas Jellinghaus <aj@dungeon.inka.de> said:
> > but : don't discuss it now. someone is working on a realy good textdb/
> > cfgtool/however-you-call-it, and i'm sure that he will do the right
> > thing. wait till it is released.
> Discuss it. I'd appreciate an open discussion.
OK, but let's move it to debian-admintool (still CCd to debian-devel at
the moment, as I'm not sure how many people are subscribed to that).
> Andreas Jellinghaus <aj@dungeon.inka.de> said:
> > > Mark Baker:
> > > > Having your database seems like a reasonable idea, but it needs
> > to be plain > text which might be slow; a db file would be faster but
> > I want to be able to > change it in a text editor. As a compromise
> > it could use the same system than the sendmail aliases: The user make
> > changes in a plain text file (/etc/aliases), but the application
> > 'compiles' this file as a db database (/etc/aliases.db)?
>
> A database of some sort (e.g. tsearch dump) would be easy to implement,
> but I don't like the idea too much. May be later (OK, statting the text
> file first is a viable way in-between).
Text-file parsing really isn't all that much slower for the amounts of
data we're talking about. In fact, since the database libraries generally
take some time to initialize their in-memory structures, I wouldn't be
surprised if the database was significantly slower, at least until we have
around 500 elements in the database.
However, the "aliases" method is a good one. It is compatible with user
modification. However, we must be careful to not allow the text file to
get too big for, say, ae or vi to handle in low-memory situations.
--
Tom Lees <tom@lpsg.demon.co.uk> http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger tom@master.debian.org for full public key (also available on keyservers)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: