Date: Wed, 04 Feb 1998 01:34:18 +0000 From: Colman Reilly <careilly@monoid.cs.tcd.ie> To: Richard Wackerbarth <rkw@dataplex.net> Cc: config@FreeBSD.ORG, mike@smith.net.au Subject: Re: WebAdmin Message-ID: <199802040134.BAA17337@monoid.cs.tcd.ie> In-Reply-To: Message from Richard Wackerbarth dated today at 16:49.
next in thread | raw e-mail | index | archive | help
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 <user> nam e. > Within each of those nodes there are entries tagged by <uid>, <gid>, > <Full User Name>, <shell>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802040134.BAA17337>