Date: Thu, 5 Feb 1998 20:38:13 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: Mike Smith <mike@smith.net.au> Cc: Colman Reilly <careilly@monoid.cs.tcd.ie>, config@FreeBSD.ORG, mike@smith.net.au Subject: Re: WebAdmin Message-ID: <l03130302b10011391304@[208.2.87.4]> In-Reply-To: <199802060042.LAA01683@dingo.cdrom.com> References: Your message of "Wed, 04 Feb 1998 22:18:52 -0000." <199802042218.WAA18923@monoid.cs.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
At 6:42 PM -0600 2/5/98, Mike Smith wrote: >This is a very salient observation. Richard and I have both tried (but >I think) failed to make the point that there are *two* things living in >the backend; the configuration _data_, and the _procedures_ that >consume that data to perform configuration. > >In Richard's case, he wants to know all the procedures in advance and >bury them in a table-based lookup. Now, I didn't say that. It is my understanding that it is possible to interpret "codelets" which are shipped down the pipe (ala java, lisp, tcl, etc.) However, there are really very few things that you can do on the back end. You can change a variable, list the tags in some database, execute a system call, etc. They are really pretty basic operations. What I want to abstract into the data tables is the organization of the data. You have already done part of this by having the file_name/method configuration file. I argue that someone who, for example, is editing user permissions does not care that the file has an ordered sequence of ":" separated values. To the person editing, he sees a "User_name", "Account_id", "Group", "Home_Directory", etc. Similarly, the widget that actually reads and writes the "/etc/master.passwd" file does not care what the label is that is attached to the third parameter. Further, this same widget can process a comma or tab delimited file. The mappings COULD be stored in the widget. However, I prefer to place them in a separate, or perhaps embedded, description table. That way we remove the meta data from the target file handlers and can maintain it separately. It is much easier to edit a table rather than change a program. > From my point of view, it'd be >easier to codify them in a procedural language-of-choice for the module >designer, but either way you look at it it is the combination of the >two that's important. I think we need to minimize the "smarts" in the back-end. Make it "lean and mean". Provide just enough capability to maintain the necessary security. Richard Wackerbarth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03130302b10011391304>