Date: Tue, 9 Jul 1996 11:27:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: croot@btp1da.phy.uni-bayreuth.de (Werner Griessl) Cc: terry@lambert.org, questions@freebsd.org Subject: Re: SysAdmin Tools - ideas wanted Message-ID: <199607091827.LAA24694@phaeton.artisoft.com> In-Reply-To: <199607091305.NAA02371@btp1da.phy.uni-bayreuth.de> from "Werner Griessl" at Jul 9, 96 01:05:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > An X-frontend for the type of admin tools we have been discussing needs
> > to be dynamically assembleable from parts so that the front end software
> > can be written once and never modified for a multitude of tools.
>
> For example with "system"-calls to the tools .
> Werner
I knew this was going to grow quickly into a full-blown discussion.
Perhaps this subject needs its own list?
Here is my take on divorcing the front end technology from the
utility<->front end data interchange grammar:
It would look like a method of defining CLI utilities (initially
by hand with UI requirements), and a UI library consumer that could
talk to a CLI written the right way to marshall the data to the
UI code and the UI event back to CLI commands.
So there is a need for two defined interfaces and a framework:
,------------------------------------------.
| UIM (User Interface Manager) |
`------------------------------------------'
/\ /\
|| ||
\/ \/
,-------------------. ,-------------------.
| CLI | | UI |
`-------------------' `-------------------'
The CLI recognizes that it has been opened via pipe, and goes into
"transaction mode". Each command is responded immediately with a
single character feedback of '0' (success) or '1' (error).
The UIM<->CLI interactor consists of <<*PROTOYPE*>>:
extern CMD *cmd_open __P(( char *cmdname));
start the CLI
extern void cmd_close __P(( CMD *cmdp));
stop the CLI
extern int cmd_send __P(( CMD *cmdp, char *cmd, int *stp));
send a command to the CLI, returning 0/1 status
extern int cmd_readln __P(( CMD *cmdp, char *bufp, int *cntp));
read a diagnostic from the CLI
extern int cmd_begin __P(( CMD *cmdp, char *cmd, int *stp));
start a context for the CLI
extern int cmd_end __P(( CMD *cmdp, int accept));
end a context for the CLI, instantiating or discarding changes
made within that context
Consider the CLI "uadmin", a user database administration agent. A
cmd_* consumer could add a user with:
CMD *uap;
int st;
uap = cmd_open( "uadmin");
...
cmd_begin( uap, "ADD USER");
cmd_send( uap, "USER=terry");
cmd_send( uap, "NAME=Terry Lambert");
cmd_send( uap, "ID=501");
cmd_send( uap, "GROUP=20");
cmd_send( uap, "GROUP+=0");
cmd_send( uap, "GROUP+=552");
cmd_send( uap, "HOME=/home/terry");
cmd_send( uap, "SHELL=/bin/csh");
cmd_send( uap, "EXPIRE_PASSWORD=NEVER");
cmd_send( uap, "EXPIRE_ACCOUNT=NEVER");
cmd_end( uap, END_ACCEPT);
cmd_close( uap);
Clearly, a UIM program could make UI calls to instantiate a dialog,
if it had knowledge of the command hierarchy, had presented a menu,
and the administrator had selected "add user" from the menu. Multiple
changes to the user's environment from the control set would be allowed;
for instance:
,-------------------------------------------------------.
| ADD USER |
,-------------------------------------------------------.
| Account Name [terry ] ,-Groups---------------. |
| User ID [501 ] | * staff (20) | |
| Password Expires [NEVER ] | wheel (0) v |
| Account Expires [NEVER ] `----------------------' |
| Full Name [Terry Lambert ] |
| Home Directory [/home/terry ] |
| Command Shell [/bin/csh ] |
| |
| ( ACCEPT ) ( CANCEL ) |
`-------------------------------------------------------'
With tab-based navigation. If I changes "terry" to "jkh" in the
account name and home directory edit areas, and changed the full name
from "Terry Lambert" to "Jordan Hubbard", the UIM would (as a result
of a field-change callback on navigation):
CMD *uap;
int st;
uap = cmd_open( "uadmin");
...
cmd_begin( uap, "ADD USER");
cmd_send( uap, "USER=terry");
cmd_send( uap, "NAME=Terry Lambert");
cmd_send( uap, "ID=501");
cmd_send( uap, "GROUP=20");
cmd_send( uap, "GROUP+=0");
cmd_send( uap, "GROUP+=552");
cmd_send( uap, "HOME=/home/terry");
cmd_send( uap, "SHELL=/bin/csh");
cmd_send( uap, "EXPIRE_PASSWORD=NEVER");
cmd_send( uap, "EXPIRE_ACCOUNT=NEVER");
cmd_send( uap, "USER=jkh");
cmd_send( uap, "HOME=/home/jkh");
cmd_send( uap, "NAME=Jordan Hubbard");
cmd_end( uap, END_ACCEPT);
cmd_close( uap);
Until the cmd_end, the edits are neither committed nor discarded.
The equivalent "command line":
# uadmin
uadmin> BEGIN ADD USER
add user> USER=terry
add user> NAME=Terry Lambert
add user> ID=501
add user> GROUP=20 0 552
add user> HOME=/home/terry
add user> SHELL=/bin/csh
add user> EXPIRE_PASSWORD=NEVER
add user> EXPIRE_ACCOUNT=NEVER
add user> USER=jkh
add user> HOME=/home/jkh
add user> NAME=Jordan Hubbard
add user> END ACCEPT
uadmin: added jkh
uadmin> ^D
#
======
Note that my front end never gained specific knowledge of the CLI tool
which it is front-ending.
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?199607091827.LAA24694>