Date: Fri, 06 Feb 1998 07:52:20 +1030 From: Mike Smith <mike@smith.net.au> To: Richard Wackerbarth <rkw@DatapleEx.Net> Cc: config@FreeBSD.ORG Subject: Re: Juliet Message-ID: <199802052122.HAA00915@word.smith.net.au> In-Reply-To: Your message of "Tue, 03 Feb 1998 08:24:05 MDT." <l03130302b0fcbea70290@[208.2.87.4]>
next in thread | previous in thread | raw e-mail | index | archive | help
(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. > 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 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. TBH, the capabilities database is *not* designed to be automatically managed; the ability to crossreference one tag from within another is a complete nightmare. > 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. > 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. > 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). > 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'm quite interested in this overall project and would like to continue > discussion of the design architecture. Thanks! -- \\ 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?199802052122.HAA00915>