Date: Thu, 5 Feb 1998 21:53:23 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: Mike Smith <mike@smith.net.au> Cc: config@freebsd.org Subject: Re: Juliet Message-ID: <l03130306b100286e86af@[208.2.87.4]> In-Reply-To: <199802060227.MAA02204@dingo.cdrom.com> References: 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
At 8:27 PM -0600 2/5/98, Mike Smith wrote: >> >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. I agree that it is only on one system. However, it is appropriately an engine to build additional layers. In the case of a single user system, I would be inclined to have it be THE engine for the whole thing. I don't see any reason that we should not write the simple user interface > >> >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. Perhaps I don't understand your meaning of the term "LDAP". If you are referring to the semantic structure, I (think that I) agree. However, if you include the actual transport protocol, I want to back up one layer and consider that LDAP is just one of many possible protocols that we might use. SNMP could be another. In the degenerate case, the transport might be nothing more than another call within the Juliet stack. Richard Wackerbarth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03130306b100286e86af>