Date: Sat, 11 Jan 1997 18:30:23 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: config@freebsd.org Subject: FreeBSD Config Manifesto (repost) Message-ID: <199701110800.SAA07676@genesis.atrad.adelaide.edu.au>
next in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701110800.SAA07676>