From owner-freebsd-config Tue Feb 3 17:38:34 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15909 for config-outgoing; Tue, 3 Feb 1998 17:38:34 -0800 (PST) (envelope-from owner-config) Received: from relay.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15840 for ; Tue, 3 Feb 1998 17:38:26 -0800 (PST) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by relay.cs.tcd.ie (8.8.7/8.8.7) with ESMTP id BAA22361; Wed, 4 Feb 1998 01:38:12 GMT Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id BAA17337; Wed, 4 Feb 1998 01:34:19 GMT Message-Id: <199802040134.BAA17337@monoid.cs.tcd.ie> To: Richard Wackerbarth cc: config@FreeBSD.ORG, mike@smith.net.au Subject: Re: WebAdmin X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 In-reply-to: Message from Richard Wackerbarth dated today at 16:49. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17332.886556058.1@monoid.cs.tcd.ie> Content-Description: text Date: Wed, 04 Feb 1998 01:34:18 +0000 From: Colman Reilly Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth said: At 4:20 PM -0600 2/3/98, Colman Reilly wrote: >Richard Wackerbarth said: > At 9:42 AM -0600 2/3/98, Colman Reilly wrote: > >Look at Mike Smiths juliet stuff. Look at my thoughts on Portia/sec urity > >stuff. > > My only objection to his design is that it is a little too specific. > I think that ALL the "back end" modules should appear monolithic and > recursively defined. For example, although the password file is orga nized > as a list of records each having fixed entries, it can be modeled as > a two level tree. The top level entries are tagged by the nam e. > Within each of those nodes there are entries tagged by , , > , , etc. >That's an objection to his implementation, not his design. It depends on >the maturity of the sub-system really. For password I agree, but for some >faster moving targets the more "black-box" approach might be better. In a n >ideal world you're right. However, I think that failure to use the monolithic structural model creat es a big problem in that all the intermediate nodes now have to be able to ha ndle information which is case dependent. If we restrict ALL the storage to the same model, then we can greatly leverage things. For example, I COULD store all of the configuration parameters in some DBMS which knows absolutely nothing a bout the real data structures. With the same primitives, I can FETCH, STORE, LIST, etc. these items. I could even handle things like the introduction of some new data type by encapsulating that data type in a string and sending it along. Only the "real" target needs to know how to format it for external consumption. >From an abstract point of view we can actually look at all the operations in Juliet as having the form of triples: (NODE,OPERATION,ARGS). Intermediate layers only need to know how to deal with these triples. This doesn't seem too onerous. Is storing this information in a DBMS a useful thing to do? I'm not convinced. This data storage model is simply a structured method of addressing data values. I believe that all the structures which we will encounter can be mapped onto it. And, at least for most of them, the mapping is trivial. But quite arbitary. We end up with SNMP, where I reset a hub by setting .hud.restart to 1. That's a pain to type and remember, and not very clean semantically. Colman