> 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. > Right, another script could be dynamically deciding on the values. Calling export at the end to save the resulting configuration does make sense. > >> 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. > Agreed. > >> 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. >
walkprop is one command that must be exclusive to interactive mode. This command waits for the user to enter a value and/or press "enter". The other commands (verify, revert, exit) make more sense in interactive mode, but doesn't hurt non-interactive modes if allowed. Another question related to non-interactive mode is whether nwamcfg exit at the first sign of error when in a non-interactive mode disregarding the remaining commands or continue with the remaining subcommands? Anurag
