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>