From owner-freebsd-config Thu Feb 5 19:02:34 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04360 for config-outgoing; Thu, 5 Feb 1998 19:02:34 -0800 (PST) (envelope-from owner-config) Received: from dingo.cdrom.com (lapdog.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04342 for ; Thu, 5 Feb 1998 19:02:32 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA02204; Fri, 6 Feb 1998 12:57:32 +1030 (CST) Message-Id: <199802060227.MAA02204@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Richard Wackerbarth cc: config@freebsd.org Subject: Re: Juliet In-reply-to: Your message of "Thu, 05 Feb 1998 20:21:59 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Feb 1998 18:27:31 -0800 From: Mike Smith Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >TBH, the capabilities database is *not* designed to be automatically > >managed; the ability to crossreference one tag from within another is a > >complete nightmare. > > I don't propose that the back end have much, if any, semantic knowledge. > In this case, all that it would know is that to display a file, it loops > over the file's tags. To display the tag, it emits the tag, displays the > aliases, and then displays the capabilities. It ends the process with an > end-of-line. Fair enough. I suspect that I may have reached that conclusion myself; it has been some little time since I worked on that module. > >Given that the method implementations are not likely to be shared > >amongst nodes of different types, ie. inheritance is likely to be > >almost nil, the extra complexity involved in this didn't seem to be > >worthwhile. > > Here, I take exception. As we start building the higher layers, I think > that you will see quite a bit more sharing. I think that the capability > should be handled in the "engine". Just think about the layers that > I will want to add when we consider the multi-machine distributed case. > I hope that I can use one engine In the multisystem case, I see the break occuring at a higher point. Juliet's offspring lives down in the interface between the LDAP server and the system's configuration files, where it is only dealing with one system. > >In the cases I've looked at so far, most of the methods have been > >largely procedural. This doesn't bend well to a table-driven approach, > >unfortunately. > > I think that you may have taken a small sample that is looking too deep. > Try backing off a bit and you may find more commonality. There will > always be those "special cases" simply because some failed to use a > common structure and did it differently. Sure. I can certainly think of a few off the top of my head. I recall you weren't suggesting table-only, which gives us the best of both worlds. > >Definitely. With the current discussions regarding implementing > >transactions via LDAP container objects, the presentation of > >transactions is likely to be much simpler (as all parameters will be > >available at the time of the transaction). > > Another transport that has merit is SNMP. I don't think the two are that > far apart. If we can keep them unified within our system, we will be > able to create a much better network administration tool. You're missing the point with SNMP though; it doesn't have any of the value-add features that make LDAP desirable. There would be nothing stopping you exporting the LDAP space through an SNMP interface of course. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\