Date: Wed, 24 Jun 1998 00:21:22 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Joao Carlos Mendes Luis <jonny@jonny.eng.br> Cc: fullermd@futuresouth.com, pvh@leftside.wcape.school.za, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration Message-ID: <10367.898672882@time.cdrom.com> In-Reply-To: Your message of "Wed, 24 Jun 1998 04:04:43 -0300." <199806240704.EAA23043@roma.coe.ufrj.br>
next in thread | previous in thread | raw e-mail | index | archive | help
> Could you please elaborate on this ? My preferred technique for
> system configuration is vi. Are there any others ? :)))
I'll assume you were being only partially facetious and actually
answer the question. :-)
A modern 90's-kinda-approach would be something like this:
[GUI tool from hell]
[generic namespace layer]
[transform layer]
.. traditional ascii files ..
The GUI tool puts up nice UI screens that allow the user to specify
details like hostname and nameserver(s) and then turns to the generic
namespace layer and says things like "host.name = foo.bar.baz" and
"host.dns = dns1.foo.org dns2.foo.org dns3.local.net", something which
your pluggable transform layer is responsible for associating with
actual fields in whichever traditional config files contain this
information.
When a value is queried in the namespace layer, the transformation
routines ensure that it's is read out of the corresponding file(s)
properly and passed up the chain. When a value is set, it gets
written back out*. This is essentially the approach (more or less)
taken by Mike Smith with his "Juliet" package, though the basic
concept has been used in other systems of this nature. It's sort of
the obvious place to put the abstraction layer if you want to be able
to create other custom file front-ends easily later. Say you wanted
to add ppp.conf to the list of things that could be "transformed" into
the generic namespace layer at a later date - you'd want it to be a
fairly straight-forward process in order to encourage people to
actually do that sort of thing.
- Jordan
* Actually, to be more accurate, the transform layer probably wouldn't
actually write stuff out on a set operation but rather upon some
other "write out all ``dirty'' variables now" action which you could
do at some checkpoint or from an explicit commit button in the UI.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10367.898672882>