Date: Mon, 18 Dec 1995 13:21:40 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dennis@etinc.com (dennis) Cc: hackers@FreeBSD.org Subject: Re: FBSD support inc. Message-ID: <199512182021.NAA12239@phaeton.artisoft.com> In-Reply-To: <199512181605.LAA21653@etinc.com> from "dennis" at Dec 18, 95 11:05:54 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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 <subcommand> [<parameter>...] <cr>
At a command line. It can also be given as:
foo <cr>
Which will enter an interactive prompt mode, eg:
foo> <subcommand> [<parameter>...] <cr>
foo> <subcommand> [<parameter>...] <cr>
foo> exit <cr>
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512182021.NAA12239>