From owner-freebsd-questions  Mon Jul  8 15:44:56 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA14429
          for questions-outgoing; Mon, 8 Jul 1996 15:44:56 -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 PAA14424;
          Mon, 8 Jul 1996 15:44:54 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA22703; Mon, 8 Jul 1996 15:39:50 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199607082239.PAA22703@phaeton.artisoft.com>
Subject: Re: SysAdmin Tools - ideas wanted
To: jim@starshine.org (Jim Dennis)
Date: Mon, 8 Jul 1996 15:39:49 -0700 (MST)
Cc: terry@lambert.org, gpalmer@FreeBSD.ORG, ron@infi.net,
        freebsd-questions@FreeBSD.ORG
In-Reply-To: <199607060818.BAA06119@starshine> from "Jim Dennis" at Jul 6, 96 01:18:51 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-questions@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 	I'd prefer to see an implementation that provided the front-end
> 	and had that front end build a command line (or series of command
> 	lines).
> 
> 	Then the interface could allow the admin to look at the 
> 	command-line (did my menu selections translate to the sort
> 	of command I would have used?) allow verification or editing
> 	and it can log the commands that were issued.

[ ... ]

> 	Not separate -- build "in front of" (from which we get the 
> 	term "front end").

The previous, indeed, implies seperate.

I was considering that the UI would invoke the command line utility
and effectively *ask* the utility for it's UI schema, and implement
certain UI-favoring command batching.

However, they will in fact be independent by this action.

For instance:

============================================================================
# uadmin
uadmin> SHOW SCHEMA
	TITLE	"User Administration"
	MENU
		TITLE	"File"
		ITEM	"Exit"		EXIT
	END
	MENU
		TITLE	"Users"
		ITEM	"Show Users..."		DIALOG user_show
		ITEM	"Add User..."		DIALOG user_add
		ITEM	"Delete User..."	DIALOG user_del
	END
	MENU
		TITLE	"Groups"
		ITEM	"Show Group..."		DIALOG group_show
		ITEM	"Add Group..."		DIALOG group_add
		ITEM	"Delete Group..."	DIALOG group_del
	END
	MENU
		TITLE	"Shells"
		ITEM	"Show Shell..."		DIALOG shell_show
		ITEM	"Add Shell..."		DIALOG shell_add
		ITEM	"Delete Shell..."	DIALOG shell_del
	END
	DIALOG user_show_d
		TITLE	"Detailed information for user $1"
		LIST FROM COMMAND "SHOW USER $1 VERBOSE"
		BUTTON	"Done"			RETURN CANCEL

	DIALOG user_show
		TITLE	"Show Users"
		BUTTON	"Ok"			RETURN CANCEL
		BUTTON	"Show details..."	DIALOG user_show_d $pick
		PICKONE pick FROM COMMAND "SHOW USER *"
		END
	END
	DIALOG user_del_confirm
		TITLE	"Delete Users
		WARNING	"This process can not be reversed"
		LIST $1
		BUTTON	"Cancel"		RETURN CANCEL
		BUTTON	"Delete"		RETURN ACCEPT
	END
	DIALOG user_del
		TITLE	"Delete User"
		BUTTON	"Cancel"		RETURN CANCEL
		BUTTON	"Delete"		IF DIALOG user_del_confirm $pick == ACCEPT THEN RETURN ACCEPT
		PICKMANY pick FROM COMMAND "SHOW USER *"
			COMMAND "DELETE USER $pick NOCONFIRM"
		END
	END
	BEGIN MENU "Delete User"
	...
============================================================================

The UI has some choices in terms of presentation, but not in terms of
organization.

> > I'd like to see one program for a front end, and multiple tools
> > that get invoked as a result of front end manipulation.
> > 
> > Tcl/tk are OK for the fornt end tool, but not the backend implementation.
> 
> 	Some parts of the back end might be implemented as 'expect'
> 	scripts.

This should be *strongly* discouraged.

One could envision placing the front end on a client system and
communicating via a "start this command" protocol over a transient
session.

For instance, you could consider a CGI script for translation to
HTML using server scripting to do administration.

This type of thing needs to be embeddable.  For instance, say I
wanted to build a print engine that was administerable via HTML,
and I wanted to use FreeBSD as a base..


> > Any opinions in this posting are my own and not those of my present
> > or previous employers.
> 
> 	I find this disclaimer amusing since you seem to be posting 
> 	from your own domain.

Simple CYA.  My mail exchanger is my employer.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.