Date: Thu, 05 Feb 1998 18:27:31 -0800 From: Mike Smith <mike@smith.net.au> To: Richard Wackerbarth <rkw@Dataplex.Net> Cc: config@freebsd.org Subject: Re: Juliet Message-ID: <199802060227.MAA02204@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 05 Feb 1998 20:21:59 CST." <l03130303b1001a4e3534@[208.2.87.4]>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802060227.MAA02204>