From owner-freebsd-hackers Mon Dec 18 12:25:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA17361 for hackers-outgoing; Mon, 18 Dec 1995 12:25:10 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA17356 for ; Mon, 18 Dec 1995 12:25:03 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA12239; Mon, 18 Dec 1995 13:21:40 -0700 From: Terry Lambert Message-Id: <199512182021.NAA12239@phaeton.artisoft.com> Subject: Re: FBSD support inc. To: dennis@etinc.com (dennis) Date: Mon, 18 Dec 1995 13:21:40 -0700 (MST) Cc: hackers@FreeBSD.org In-Reply-To: <199512181605.LAA21653@etinc.com> from "dennis" at Dec 18, 95 11:05:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk > >> No, it's how do you deal with suddenly being forced to do release > >> engineering for 12 platforms where one was formerly enough to drive > >> the release engineer to early retirement? > > > >By making the administrative interfaces for all system identical, and > >by data-driving those areas where it's not possible to resolve the > >interface conflicts. > > > >CV: my more recent articles on logical device management in a devfs > >framework. > > > >It's an engineering problem, not a management problem. > > note that this often leads to widespread mediocrity. Like data driving the WWW interfaces instead of writing site specific clients has "resulted in mediocrity"? With due respect, it is possible to have a client/server mechanism with a data driven front end which operates at a high level of data abstraction *without* sacrificing Q/A standards. WWW proves this to no end. Again: this is an engineering problem. Consider that the framework hierarchy of the presentation interface need bear no resemeblence to the underlying interface. An example: I have a command "foo". It controls the print system setup. The command can be given as: foo [...] At a command line. It can also be given as: foo Which will enter an interactive prompt mode, eg: foo> [...] foo> [...] foo> exit Finally, a user interface program operatining under data driven selection, can popen(3) "foo" and extablish a pipe for interactive control ("foo" uses "isatty" to determine that it should not put out the prompt string). Through a series of interactive queries, the user interface program builds a list of possible interface states and puts up objects relative to the supplied order for output of a "menu" or some other designated internal command which will retrieve the interface objects in an interface usable format. It then builds the interface based on the output of the program, including subfunction menus, etc. This buys a command line mechanism for committing/not committing (quit instead of exit) changes as a group, resetting changes to defaults, resetting changes to previous values prior to the commit actually taking place following modifications at the user interface level, etc. The "foo" comand could be a perl program. It could be a shell script. It could be the "sysctl" or "ncrcontrol" or "vidcontrol" programs, or it could be an as-yet-unwritten-program. Data driven partitioning and slice and mount control for devices would require additional interfaces for the devfs (said interfaces have not yet been implemented). What you get out of this is the ability to build a single apparently unitified graphical or text user interface with the same set of tools that allow you to do things at the command line as well. There is nothing in this that requires that the results be mediocre. And because the interface presentation is abstracted from its core and implementation of schema, the resulting interface is platform independent, even though the underlying commands (and thus the intermediate framework) can be identical. Just like HTML or SQL servers are platform dependent, HTML/SQL is platform independent, and the client interface is seperable and not bound to a particular machine architecture for implementation (only for execution). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.