Date: Wed, 04 Feb 1998 22:18:52 +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: <199802042218.WAA18923@monoid.cs.tcd.ie> In-Reply-To: Message from Richard Wackerbarth dated Tuesday at 21:02.
next in thread | raw e-mail | index | archive | help
[Is anyone except me, Richard and Mike getting this?]
At 7:34 PM -0600 2/3/98, Colman Reilly wrote:
>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.
[...]
In general, we need to be able to build "transactions" which are composed
of multiple operations which are then taken on an "all or none" basis.
The easiest way to do this may be to build a "shadow" of the target system
and manipulate that image rather than forcing the target to support the
ability to back out partial transactions, etc. In such a case, the "shadow"
is really just a DBMS.
When all you have is a hammer ... It's not just a DBMS. I really don't think
the model fits the problem. I can't construct a reasonable argument for this
opinion right now, and I'd be happy to be convinced otherwise. I'll construct
a reasoned argument later. Must try and write some of these responses earlier
in the day occasionally. :-)
Actually, the problem here is probably a requirements mismatch. I don't
believe that the configuration/system management task can be simply reduced
to reading/writing parameters. The objects being managed are generally more
complex than that, and we need to keep as much of the target specific stuff
right at the back end of the system.
>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.
I agree that SNMP is not a "friendly" communications tool for humans.
However, it does have the virtue of "simplicity of implementation"
at the machine level. I see no reason why it could not be used for the
"back-end" language. However, just as HTML is not the "front-end" language,
link adapters would perform the translations.
I'm worried that we'll end up translating things into easy to implement too
early, with the result that the semantic richness of the system is lost
before any of the intermediate layers have a chance to do anything with it.
>From the point of access control is is nice to have available the operations
like append, restart, create which express the meaning of the transaction in
order to make it easier to write (say) ACLs. Would you rather rather write
deny "write" on ".hub.controls.reset" to richard
or
deny "hub reset" to richard
I think the latter might make life a litle easier, and that's fairly far into
the backend. When you start thinking about expressing rules for a consistency
checker it gets even worse.
Don't misunderstand. I am not advocating that we use any particular mechani
sm
as the transport layer(s). Rather, I think we need to develop a modular
structure that allows us to "mix and match" pieces. The front-end and back-
end
languages are the connecting pieces. The front-end needs to be sufficiently
friendly that it can be used as a command line language. The back-end needs
to have simple-to-implement functionality.
Well, I'm very much in favour of the mix-and-match philosophy.
Colman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802042218.WAA18923>