Date: Thu, 5 Feb 1998 20:21:59 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: Mike Smith <mike@smith.net.au> Cc: config@freebsd.org Subject: Re: Juliet Message-ID: <l03130303b1001a4e3534@[208.2.87.4]> In-Reply-To: <199802060119.LAA01807@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 7:19 PM -0600 2/5/98, Mike Smith wrote: >(cc'd to -config; Richard I hope you don't mind, but I think your >points deserve wider coverage.) > >> I found a little time to look at what you have started with "Juliet". >> >> Here are my initial observations: >> >> 1) I like the idea of using an extensible language system such as tcl. >> However, if we were to use this for "sysinstall", would the "bloat" of >> that package be a problem? Perhaps we will need a stripped down version >> to fit on a floppy.... > >Tcl is moderately compact, but TBH I don't see any of this being on the >install floppy. The current install floppy tries to do everything >itself, which is a fundamental mistake. Without straying too far from >the topic at hand, the install floppy's task is likely to be >significantly rightsized fairly soon. Bring up just enough of a kernel to talk to the keyboard/screen and SOME other source for the next stage of the process. If we can get out to a CD or the Net, we've got it made. Actually, with the CD, we might be able to directly boot the next stage which can run from RO store. Now all we have to do is format the first disk so that we have somewhere to really store things. .... :-) >> 2) I think that it is a mistake to add ANY extra methods to the primitive >> data types. For example, in the case of the "cap" files, you have the >>concept >> of a <tags> and, within the tag, <caps> and <aliases>. These are all visable >> at the interface. This requires that special methods are required for >> adding a <cap>, etc. >> I think that it would be better to use a unified structure whereby the >><caps> >> are a sub-node of the individual <tag> just as the <tag> is a sub-node >>of the >> <file>. That would allow the use of the same methods (and, by extension, UI) >> to handle either. > >This design was actually fairly intentional. Juliet doesn't (perhaps >unfortunately) hide any of its internal implementation from the >consumer interface. It's not actually intended that a consumer work >with the primitives. I agree. The complaints from others about the "friendlyness" is, IMHO, misplaced. These commands are more like the machine language rather than the high level languages that we humans use to describe algorithms. It has been a long time since I had to enter programs with switches and pushbuttons and decypher hex dumps. >I take your point though. All that would be required in terms of >methods would be one one the file to create a tag, and one on the tag >to create a cap. Precisely. >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. >> 3) I would use a slightly different "method" scheme based on the inherited >> concept of classes. Rather than directly implement each method for each >>node, >> I would have each node have an attribute which describes its class of >>methods. >> Further, within the method handler, I would allow inheritance of methods >>from >> another class. > >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 >> 4) As much as possible, I would keep the data table driven. That way we >>don't >> have to change the engine in order to keep up with changes in the database. > >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. >> 5) We should be able to use the same interface to access the target >> description, the local working store, and reference definitions. That >> way, I could implement everything either locally or remotely and reuse >> interface modules. > >At this point in time, it is most likely that Juliet will become a >backend for the UMich LDAP server. This prettymuch guarantees a common >interface. > >> *** My conceptual model *** >> 1) Everything is processed within the framework of transactions. >> We may, or may not, worry about recovery in error conditions. > >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. >> 2) The system consists of a number of subsystems: > >I'd like to see your response to Terry's whiteboard scrawl on this; I >can send it to you if you didn't get it (are you on -config)? I am now and have been for a day or two. However, I couldn't find any archive to review. :-( Please send a copy. >> I'm quite interested in this overall project and would like to continue >> discussion of the design architecture. > >Thanks! Richard Wackerbarth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03130303b1001a4e3534>