I see the essence of what you propose. A bit of "interactivity" when
software knows it's talking to a human, is probably desirable (if the software
does not overdo it).
Technically, it is generally possible to find out if an asadmin command
is being run as a part of script or not. A given command can behave differently
based on it.
Two possibilities emerge:
- Stick to rather "strict" interface when command executes as part of script.
- Be creative and interactive when a human executes commands.
But that gives rise to two flavors of each command and is rather expensive.
Can a reasonable compromise be made if we make a simplifying assumption that
"multi-mode" execution of asadmin defaults to interactive use and "single-mode"
execution follows strict interface?
e.g.:
$asadmin (Enter)
$asadmin> Enter a command or "quit": deploy
$asadmin> Enter the path of deployable: foo.war
$asadmin> Enter the context-root[foo]: bar
...
Command "deploy" executed successfully and exited with code 0.
$asadmin> Enter a command or "quit": create-jdbc-connection-pool
$asadmin> Enter the name in the naming service (JNDI): jdbc/orapool
...
$>asadmin>Enter a command or "quit": Quit
The syntax for single-command is like-wise, but follows syntax and
accepts correctly spelled options case-insensitively.
I always believed (as a user) that entering into multi-mode was akin
to declaring my consent for interaction (aka liveliness).
Thoughts?
- Kedar
Vince Kraemer wrote:
> This is starting to sound like the discussion that we had some time back
> about something similar to the 'Did you mean: x y z?" feature that
> Google has...
>
> See
> https://glassfish.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=1660.
>
> This lead to the great work that Jane did with CLI back in V2:
> http://blogs.sun.com/janeyoung/entry/finding_cli_commands_in_glassfish
>
> Now it is time to take the next step... What is an example of the next
> step... See http://userscripts.org/scripts/show/9514
>
> vbk
>
> Other notes in-line...
>
> Kedar Mhaswade wrote:
>>
>>
>> Jerome Dochez wrote:
>>> I was talking to Jane about this yesterday, We need to ensure we are
>>> satisfying the CLIP requirements but that's definitely my feeling too,
>>>
>>> just like if someone types --contxetroot, we should interpret it as
>>> --contextroot...
>>
>>
>> Hmm. That's interesting but difficult to get right and has implications
>> on "interface" definition and compatibility.
>> Maybe someone did want to get an error back
>> on typo? (Otherwise we might have to support all the typos forever!)
>
> we might not support typos in scripts... but we want to try to make it
> easy for the user to keep working....
>
> Our CLI is currently like Google search, but we force the user to retype
> the query... instead of click the "did you mean" link....
>
> let's extend the example from jane's blog entry...
>
> USER> asadmin create-domian --adminport 4848 --user admin foo
>
> current return text>* **Closest matched command(s):
> create-domain*
> Use "help" command for a list of valid commands.
>
> proposed return text> *Closest matched command(s):
> create-domain*
> Use "help" command for a list of valid commands.
> Execute "asadmin create-domain --adminport 4848 --user admin foo"?
>
>
> If the user enters y/yes/true... the proposed command would be executed.
>
> In cases where there are multiple choices of the most likely correct
> choice, the Execute part of the return text would not appear.
>
> I realize that this isn't "clean" from a defined interface
> perspective... but, humans aren't "clean" from a defined interface
> perspective, either.
>
> This is the kind of feature that can delight a user when they discover
> it...
>
>>
>> Case-sensitivity is slightly different. For a long option, a "correct"
>> spelling in any case could be accepted as valid without huge (as in
>> difficult to deal with) implications.
>>
>> Incidentally, I think we need to consider the exit codes from CLI with
>> some seriousness. I have started a discussion topic at:
>> http://wiki.glassfish.java.net/Wiki.jsp?page=ProsAndConsOfAsadminExitCodes
>>
>> and will be adding content to it soon. A reasonable exit code (and
>> message)
>> would indicate the typo like: "Did you mean --contextroot instead"? would
>> lead to better overall user experience.
>
> I agree. But we can go even higher then that...
>>
>> Regards,
>> Kedar
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>