From owner-freebsd-config Thu Jan 9 19:23:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA10534 for config-outgoing; Thu, 9 Jan 1997 19:23:47 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA10529 for ; Thu, 9 Jan 1997 19:23:44 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA01710 for config@freebsd.org; Fri, 10 Jan 1997 13:53:41 +1030 (CST) From: Michael Smith Message-Id: <199701100323.NAA01710@genesis.atrad.adelaide.edu.au> Subject: Config Manifesto comments? To: config@freebsd.org Date: Fri, 10 Jan 1997 13:53:39 +1030 (CST) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, it's been more than a week since I posted the first-draft FCF proposal, and the silence has been deafening. Should I take it then that 'vi' is the configuration tool-of-choice and pack the whole thing in? -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-config Fri Jan 10 01:44:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA03075 for config-outgoing; Fri, 10 Jan 1997 01:44:15 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA03070 for ; Fri, 10 Jan 1997 01:44:12 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id BAA06156; Fri, 10 Jan 1997 01:44:04 -0800 (PST) To: Michael Smith cc: config@freebsd.org Subject: Re: Config Manifesto comments? In-reply-to: Your message of "Fri, 10 Jan 1997 13:53:39 +1030." <199701100323.NAA01710@genesis.atrad.adelaide.edu.au> Date: Fri, 10 Jan 1997 01:44:04 -0800 Message-ID: <6152.852889444@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Well, it's been more than a week since I posted the first-draft FCF > proposal, and the silence has been deafening. > > Should I take it then that 'vi' is the configuration tool-of-choice and > pack the whole thing in? No, please don't. Assume instead that those of us who care were either preparing for or are now directly at USENIX. :-) I've spent a lot of time talking with BSDI about their installation and system management interface which will debut in 3.0, BTW. Guess what - it's HTML based. When I raised the objections that others have raised about the limitations of crafting good looking interfaces in HTML, the response was "yeah, we know, but face it - there's a GUI standard now, the HTML browser is it, end of story. Learn to live with it, warts and all, OK?" They also don't feel that it's worthwhile to attempt to use lynx or make the product lynx friendly. In BSD/OS 3.0, you're asked enough questions to configure the network and then optionally start the X server + a browser (in this case Netscape since they're licensed for it) or simply go to another station if you're not able to run a browser (say because you're on a serial console). You know what? I think they're right. Technology is simply moving so fast that these assumptions are no longer unreasonable, nor would they be by the time we actually deployed our own system. How that effects the romeo/juliette abstraction I'm not sure, exactly, but I still like the idea of keeping all the "system properties" in property lists (which can be arbitrarily nested) and making them the responsiblity of a single daemon. That allows you to write multiple agents for frobbing the data, not just our nifty installation and setup tool. I guess that means that Juliette is safe. :-) Romeo might need an HTML hair transplant, but I need to go back and read the spec in more detail before I respond. This is on my post-conference TODO list so please don't despair, Mike! :-) Jordan From owner-freebsd-config Fri Jan 10 03:11:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA06207 for config-outgoing; Fri, 10 Jan 1997 03:11:33 -0800 (PST) Received: from camj.com ([207.51.232.30]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA06200 for ; Fri, 10 Jan 1997 03:11:29 -0800 (PST) Received: (from root@localhost) by camj.com (8.8.4/8.7.3) id FAA00290; Fri, 10 Jan 1997 05:11:18 -0600 (CST) Date: Fri, 10 Jan 1997 05:11:18 -0600 (CST) From: Charlie Root Message-Id: <199701101111.FAA00290@camj.com> To: config@freebsd.org, msmith@atrad.adelaide.edu.au Subject: Re: Config Manifesto comments? Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Apparently your manifesto got lost. Could you resend to me at least? Thanks, From owner-freebsd-config Fri Jan 10 23:47:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA05170 for config-outgoing; Fri, 10 Jan 1997 23:47:05 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA05165 for ; Fri, 10 Jan 1997 23:47:02 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id SAA07634; Sat, 11 Jan 1997 18:16:54 +1030 (CST) From: Michael Smith Message-Id: <199701110746.SAA07634@genesis.atrad.adelaide.edu.au> Subject: Re: Config Manifesto comments? In-Reply-To: <6152.852889444@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 10, 97 01:44:04 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 11 Jan 1997 18:16:52 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, config@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'll reply to this in more detail later, as I have a few domestic problems to deal with first (does "local redback plague" mean anything to you?), but in the hope that I catch you before it's too late... Jordan K. Hubbard stands accused of saying: > HTML, the response was "yeah, we know, but face it - there's a GUI > standard now, the HTML browser is it, end of story. Learn to live > with it, warts and all, OK?" I disagree. Violently. I'll accept that a GUI may be mandatory (I know that others will puke here), but HTML does _not_ cut the mustard in any sense of the word. Java? Maybe; I doubt you'll find me using it in the short term, but I suspect we can find someone with some spare brainspace. > How that effects the romeo/juliette abstraction I'm not sure, exactly, Well, IMHO it means that BSDI have to extract whatever squeaking object is blocking whichever orifice that has prevented them from having Netscape support plugins on the BSD/OS versions to date. Or we try to find a kindly soul at Netscape that will contract someone to build a FreeBSD version of Netscape. Hell, I'd do it. > setup tool. I guess that means that Juliette is safe. :-) Romeo might > need an HTML hair transplant, but I need to go back and read the spec > in more detail before I respond. This is on my post-conference TODO > list so please don't despair, Mike! :-) Basically, it means that the text-mode UI is toast, and Romeo becomes Tcl Plugin/Java code. Sorry Jan. It also means that you won't be able to run the configuration client on anything less than a P100 with 32M, courtesy of Bloatscape. > Jordan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-config Sat Jan 11 00:00:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA05442 for config-outgoing; Sat, 11 Jan 1997 00:00:30 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA05435 for ; Sat, 11 Jan 1997 00:00:27 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id SAA07676 for config@freebsd.org; Sat, 11 Jan 1997 18:30:24 +1030 (CST) From: Michael Smith Message-Id: <199701110800.SAA07676@genesis.atrad.adelaide.edu.au> Subject: FreeBSD Config Manifesto (repost) To: config@freebsd.org Date: Sat, 11 Jan 1997 18:30:23 +1030 (CST) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a repost of the FCF manifesto, as it appears to have missed some people. Note that it may be a little dated by Jordan's recent comments; I'll worry about updating it once I have all these black crawling things out of my house. FreeBSD Configuration Framework Manifesto, version 0. ================================================================= Comments, discussion etc. to config@freebsd.org 1. Goals -------- The FreeBSD Configuration Framework (FCF) aims to provide a modular, extensible configuration mechanism for the FreeBSD operating system, installed software and hardware. Principal design goals : - Client/server model, with a distinct and well-defined interaction protocol. - High degree of modularity, with clearly-defined inter-module protocol and definite disposition of module responsibilities. - Client UI abstraction sufficient that client modules need not specifically handle interface details. 2. Architecture --------------- The FCF can be viewed as two seperate entities, the server (Juliet) and the client (Romeo) (Codenames are optional but trendy). Server architecture - - - - - - - - - - Juliet consists of a framework providing module support and intermodule communications, and modules which provide basic functionality elements. The framework manages the loading/unloading(/upgrading/downgrading) of modules, intermodule communications (all messages between modules pass through the framework) and communications with Romeo. Modules may provide basic services (eg. the 'sysconfig' module may provide facilities for altering configuration values in the /etc/sysconfig file), or high-level abstract services (eg. the 'security' module would be able to find and manipulate security-related options in other modules). Client architecture - - - - - - - - - - Romeo provides user-interface features (including the abstract UI model discussed later) and other module support functions, and communications support for talking to Juliet. Modules in Romeo will generally not interact with one another other than indirectly via Juliet. 3. Communications ----------------- Romeo explicitly invokes Juliet on the target system using rsh or ssh; the latter being preferred for security reasons. Messages are passed between the two as newline-terminated ASCII strings of arbitrary length, comprising a token, a space, and arbitrary data. The token will identify the intended recipient of the message and the sender. Modules are identified in a path-style notation, with alphanumerical path components and with ':' as a seperator. (This is naturally arbitrary, and if it conflicts with a likely implementation language will be changed.) A sample conversation may look like : net:conf:interfaces,net:conf list interfaces net:conf,net:conf:interfaces interfaces lo0 ed0 ed1 net:conf:interfaces,net:conf ifdetail ed0 net:conf,net:conf:interfaces ed0 inet 10.0.1.2 netmask 255.255.255.0 net:conf:interfaces,net:conf ifconfig ed0 inet 10.0.1.3 netmask 255.255.255.0 Here we have the net:conf (network, configuration) interface-management module in Romeo asking the net:conf module in Juliet for a list of network interfaces, then getting the details for ed0, and then changing them. Inside Juliet, the net:conf module would have asked the (eg.) files:sysconfig module for details from /etc/sysconfig, and so on. This simple, text-only protocol makes it straightforward for clients other than Romeo to interact with Juliet, which may be useful for automated tasks that Romeo is likely to be poorly suited to. Intermodule communications within Juliet are performed similarly; messages are either requests (control is passed by the requesting module to the dispatcher with the message, and thence to the recipient) or responses (control is passed back with the response). Again, all messages are ascii objects. It is also possible for Juliet to post messages to Romeo, eg. as a side effect of another activity or in response to some other circumstance. These messages may be optional (if the recipient module is not currently loaded/active the message is dropped) or mandatory (the required module is loaded if required before the message is delivered). 4. Implementation ----------------- The core of both Romeo and Juliet will be written in Tcl. This is at least partly developer bias, however Tcl is well suited to the modular nature of this application. The X-windows UI components of Romeo will be implemented using Tk, and (probably) the Tix toolkit. The low-level text UI components will probably be implemented with a custom library currently under development for this project. Modules for Romeo and Juliet can be implemented in any language suitable to the task or the developer, eg. Tcl, Perl, C, C++ etc. Non-Tcl modules will be automatically wrapped and loaded to suit their implementation. User Interface - - - - - - - The interface between modules in Romeo and the user interface has yet to be solidified. It is accepted as essential that both character-mode and graphical (X-based) interfaces are desirable, and that implementing each interface using seperate code within each module is not an optimal solution. It is proposed that a high-level abstraction be devised which will allow for the layout and management of the interface (possibly with hinting or even explict per-model details) by the UI code without direct intervention by the module. Discussions on this are beyond the scope of this document at this stage, but must form a major part of the development of Romeo. ============================================================================== This document is a Work In Progress. Discussion and submissions will be gratefully received. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-config Sat Jan 11 02:26:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id CAA09422 for config-outgoing; Sat, 11 Jan 1997 02:26:12 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA09417 for ; Sat, 11 Jan 1997 02:26:08 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id CAA11030; Sat, 11 Jan 1997 02:26:00 -0800 (PST) To: Michael Smith cc: config@freebsd.org Subject: Re: Config Manifesto comments? In-reply-to: Your message of "Sat, 11 Jan 1997 18:16:52 +1030." <199701110746.SAA07634@genesis.atrad.adelaide.edu.au> Date: Sat, 11 Jan 1997 02:25:59 -0800 Message-ID: <11026.852978359@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'll reply to this in more detail later, as I have a few domestic > problems to deal with first (does "local redback plague" mean anything > to you?), but in the hope that I catch you before it's too late... Those are Kangaroos, right? I thought that's what the roo-guards on your trucks were for. :-) > I disagree. Violently. I'll accept that a GUI may be mandatory (I > know that others will puke here), but HTML does _not_ cut the mustard > in any sense of the word. Java? Maybe; I doubt you'll find me using > it in the short term, but I suspect we can find someone with some > spare brainspace. It may offend your olfactory nerves, but I really do think it can be made to work, Mike. I've *seen* the system work for the Empac server installation, and that was using old and crufty early 90's technology. I really find it hard to believe that we couldn't meet or exceed their achievement (or BSDI's, for that matter - they made it work too) using the benefit of hindsight. No offense to Jan intended, but I'm pretty pessimistic at this point that we'll ever get a usable curses toolkit and/or get one which doesn't also make us upchuck. People have been trying to crack that nut for years, and the only folks who came even close were the SCO folks, and they're not going to release that. > Well, IMHO it means that BSDI have to extract whatever squeaking > object is blocking whichever orifice that has prevented them from > having Netscape support plugins on the BSD/OS versions to date. Apparently this is a problem which Netscape is having with BSDI's mutant object format. I think the wait is now on for BSDI to make their planned switch to ELF, after which we may revision the situation again. Also, Netscape 4.0 for BSD/OS will be linked shared so we won't be able to run it anyway. With 4.0, it'll be back to the Linux netscape for us, I'm afraid. > Or we try to find a kindly soul at Netscape that will contract someone > to build a FreeBSD version of Netscape. Hell, I'd do it. Hell, I've offered to go down there myself and do it in person for free, NDAs and all. Netscape was unmoved. :-) > Basically, it means that the text-mode UI is toast, and Romeo becomes > Tcl Plugin/Java code. Sorry Jan. No, it becomes HTML. I never intended to use Netscape in this equation since we aren't licensed for it anyway. We can distribute Mosaic, arena, chimera and a few other graphical browsers as options. Jordan From owner-freebsd-config Sat Jan 11 06:42:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA19345 for config-outgoing; Sat, 11 Jan 1997 06:42:40 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA19340 for ; Sat, 11 Jan 1997 06:42:37 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id BAA08271; Sun, 12 Jan 1997 01:12:29 +1030 (CST) From: Michael Smith Message-Id: <199701111442.BAA08271@genesis.atrad.adelaide.edu.au> Subject: Re: Config Manifesto comments? In-Reply-To: <11026.852978359@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 11, 97 02:25:59 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 12 Jan 1997 01:12:29 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, config@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > I'll reply to this in more detail later, as I have a few domestic > > problems to deal with first (does "local redback plague" mean anything > > to you?), but in the hope that I catch you before it's too late... > > Those are Kangaroos, right? I thought that's what the roo-guards on > your trucks were for. :-) No; redbacks are venomous spiders, a somewhat larger relative of the beastie you call the "black widow". They're aggressive and, with the rash of hot weather we've just had, irritable and on the move looking for somewhere cooler to live. We don't get too many 'roos downtown. As Julian what a decent roo will do to the front of what you call a 'truck'. You need the arm motions to appreciate it really 8) > It may offend your olfactory nerves, but I really do think it can be > made to work, Mike. I've *seen* the system work for the Empac server > installation, and that was using old and crufty early 90's technology. > I really find it hard to believe that we couldn't meet or exceed their > achievement (or BSDI's, for that matter - they made it work too) using > the benefit of hindsight. Well, I'm happy to be convinced otherwise, but I remain skeptical. If you can come up with something that can handle interactive activities, and asynchronously-posted server-side events without a client-side scripting language, then I'll happily go along with it. I simply fail to see how a fill-out-the-blanks interface, which is all that HTML can offer, is going to provide this, and I refuse to subscribe to the 20-billion-flies argument. > Also, Netscape 4.0 for BSD/OS will be linked shared so we won't be > able to run it anyway. With 4.0, it'll be back to the Linux netscape > for us, I'm afraid. Well that's just bloody wonderful, isn't it? I can just guess how well _that_ is going to be received. 8( > No, it becomes HTML. I never intended to use Netscape in this equation > since we aren't licensed for it anyway. We can distribute Mosaic, > arena, chimera and a few other graphical browsers as options. The only thing that we win on using an HTML interface in this case is the ability to display on non-x-capable (Windows, Mac) systems. I don't think that this is an acceptable tradeoff. > Jordan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[