On Wed, 24 Dec 2008 10:34:47 -0500
Anurag Maskey <Anurag.Maskey at Sun.COM> wrote:
> Hmmm ..... I think this spec has to change. Commit should be allowed in
> the non-interactive mode also. If all changes are implicitly committed,
> then it means calling nwam_*_commit() after every "set" subcommand in
> file and command line mode, This is quite inefficient.
Taking a step back I wonder why we differentiate between interactive
and non-interactive modes at all? It seems to me that we have made
choices based upon which mode each command makes sense in based upon an
unstated use model. I believe we either need to make that use model
and those choices explicit in the design document or remove the
differences.
The use model I'm thinking of is the one in which the user tries things
out interactively and then scripts it up for mass use. In this model
commands should act the same as much as possible so that the user
doesn't have to re-debug the script.
>
> Also, nwamcfg makes very little distinction between where it is getting
> the commands from. It doesn't care if the commands come from the
> interactive user or a file or command line. Also, the command file uses
> "end" to save and go up one scope (end implicitly calls commit).
>
> In command-line mode, the commit is implicit after the last command, but
> the user should be allowed to explicitly commit anytime. (command-line
> mode is typing commands after "nwamcfg" at the prompt, eg. $nwamcfg list
> or $nwamcfg "select ncp user; list")
>
> Let's revisit where I think the commands should be allowed. The current
> implementation in the gate may be different than what's listed below.
>
> cancel: all three modes (interactive, file, command-line)
> clear: all three modes
> commit: all three modes
> create: all three modes
> destroy: all three modes
> end: all three modes
> get: all three modes
> select: all three modes
> set: all three modes
>
> export: command-line and interactive mode
While it seems less useful in non-interactive mode why are you
restricting it? Maybe somebody builds input to nwamcfg dynamically and
they want to save off the result at the end.
> help: command-line and interactive (doesn't make sense in file mode)
I guess somebody could be running us over a pty to implement some other
interface and have a pass through for help. That is a big stretch
though.
> list: command-line and interactive (file mode too? maybe script wants to
> parse output?)
An argument like export.
>
> exit: interactive mode only
> revert: interactive only
> verify: interactive only
> walkprop: interactive mode only
A fairly weak argument like help.
I think the burden should be on why are interactive and non-interactive
mode different. It seems to me like coding them to be different would
actually be more work for little to no gain. Additionally we will have
to make it clear in the documentation when they are different which
could be confusing unless we have strong and clear reasons.
mph
>
> Anurag
>
> Lizhong Li wrote:
> > Anurag,
> >
> > According the manpage
> > http://opensolaris.org/os/project/nwam/p1spec/ui/CLI/,
> > commit is only meaningful in interactive mode, so I think the following
> > command should exit with an error, or are there other consideration I
> > don't know ?
> >
> > firering:exp# nwamcfg "select ncp myncp1; commit"
> > firering:exp# echo $?
> > 0
> > firering:exp# uname -v
> > nwam1-build:2008-12-18
> >
> >
> _______________________________________________
> nwam-dev mailing list
> nwam-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/nwam-dev
