From owner-freebsd-questions Tue Jul 9 11:33:31 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA26834 for questions-outgoing; Tue, 9 Jul 1996 11:33:31 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA26823 for ; Tue, 9 Jul 1996 11:33:28 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA24694; Tue, 9 Jul 1996 11:27:47 -0700 From: Terry Lambert Message-Id: <199607091827.LAA24694@phaeton.artisoft.com> Subject: Re: SysAdmin Tools - ideas wanted To: croot@btp1da.phy.uni-bayreuth.de (Werner Griessl) Date: Tue, 9 Jul 1996 11:27:47 -0700 (MST) Cc: terry@lambert.org, questions@freebsd.org In-Reply-To: <199607091305.NAA02371@btp1da.phy.uni-bayreuth.de> from "Werner Griessl" at Jul 9, 96 01:05:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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.