[jboss-as7-dev] proposed cli changes

Tue Mar 15 10:13:33 EDT 2011

On 3/15/11 4:01 AM, Max Rydahl Andersen wrote:
>> No promises this will continue to be the case, but for now it's a
>> convenient way to keep command history -- just keep the process alive. ;)
>
> Why wouldn't this continue to be the case ? it's all pretty stateless HTTP operations ain't it ?
>

It uses the native API. I don't see why it can't continue to be the 
case, and I want it to be the case, but I didn't promise it because the 
comment was just a quick FYI tangent on a thread.

> /max
>
>>
>>>>
>>>>> +1, Max's suggestion make sense to me.
>>>>>
>>>>> On 07/03/2011 19:03, Max Rydahl Andersen wrote:
>>>>>>>>> Max, Emanuel and I discussed the usability aspects of the cli today. We
>>>>>>>>> agreed on the following:
>>>>>>>>>
>>>>>>>>> 1) drop the '/' prefix for the commands;
>>>>>>>>>
>>>>>>>
>>>>>>> How does this relate to the discussion of low-level commands vs high level?
>>>>>>
>>>>>> It was a long discussion - but let me see if I can summarize what drove this.
>>>>>>
>>>>>> There are some subjectivity in parts of this but mostly its driven by not making the
>>>>>> shell being "weird" compared to what users otherwise sees in the wild...thus / is suggested as a separator to match filesystem and url paths.
>>>>>>
>>>>>> When starting up the cli it also just feels so weird and wrong to require typing / to get to a command
>>>>>> (unless of course you are an IRC guy - but thats not really the audience we cater to is it  ?:)
>>>>>>
>>>>>> Thus my suggestion was to make the logic so if you just type a string, i.e. "help"
>>>>>> then it will mean "execute the command or alias named help" nothing else. Just like a normal shell.
>>>>>>
>>>>>> If you want to "execute" something in the current node/path you need to (just like in a bash/zsh etc. without a PATH setup)
>>>>>> to put ./<path>:<operation>     to execute it.
>>>>>>
>>>>>> so the suggested syntax allow you to type things like:
>>>>>>
>>>>>> jboss-admin.sh
>>>>>> $ connect
>>>>>> [/]  # default connect is root.
>>>>>> $ cn subsystem=web
>>>>>> [/subsystem=web]
>>>>>> $ :read-resource-configuration    #executing operation against current node.
>>>>>> $ ..:read-resource-configuration # executing against parent node (not sure if this should actually be ../:read-resource-configuration?)
>>>>>>
>>>>>> $ cn ../hosts=undefined/server=server1  # up one level and into the path.
>>>>>> [/hosts=undefined/server=server1]
>>>>>> $ /subsystem=web:read-resource-configuration # execute based on root ignoring the current node
>>>>>> [/hosts=undefined/server=server1]
>>>>>> $ rr     # a command/alias that will execute :read-reosource-configuration
>>>>>> <return the result>
>>>>>>
>>>>>> We even discussed if it should be legal to do:
>>>>>> [/hosts=undefined/server=server1]
>>>>>> $ =server2:read-resource-configuration    # execute the operation in context of current nodetype, but change the name vs requiring eplicit typing.
>>>>>>
>>>>>> $../server=server2:read-resource-configuration
>>>>>>
>>>>>> With this tab completion still can know if it should be completing names, children or operations AND we get a "navigational" syntax that mimicks  well known paths.
>>>>>>
>>>>>> We could even go all the way and allowed  / instead of = you could actually copy the paths directly between your curl/browser and the cli - only diff would be the operation syntax.
>>>>>>
>>>>>> Hope that gave some more context - at least with these changes the CLI navigation doesn't feel so alien to newbies...their brains can spend more
>>>>>> energy to actually understand the semantics of the operations than the syntax.
>>>>>>
>>>>>> /max
>>>>>>
>>>>>>>
>>>>>>> Other than that question, what you describe here sounds fine (including
>>>>>>> the 'cd' alias, which I know would be what I'd naturally use).
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>> 2) instead of '~' signifying the root node use '/';
>>>>>>>>>
>>>>>>>>> 3) instead of ',' as a node separator in the address (node path) use
>>>>>>>>> '/'. so the format of an operation will look like
>>>>>>>>>
>>>>>>>>> [node-type=node-name (/node-type=node-name)*] : operation-name
>>>>>>>>> ['('param=value (,param=value)*')']
>>>>>>>>>
>>>>>>>>> This (2 and 3) will make the path look more linux-like, so hopefully
>>>>>>>>> more friendly for an admin.
>>>>>>>>>
>>>>>>>>> 4) in the same spirit, the tab-completion for operations will start with
>>>>>>>>> './', e.g. './subsystem=web/connector=http:read-resource'
>>>>>>>>
>>>>>>>> or '/' to start from the root (if the current address (prefix) is
>>>>>>>> something other than the root). e.g.
>>>>>>>>
>>>>>>>> [subsystem=web/connector=http] /subsystem-threads:read-resource
>>>>>>>>
>>>>>>>>> 5) for the command names, Max likes
>>>>>>>>> cn (change node) - current /prefix or /to.
>>>>>>>>> cwn (current working node) - again current /prefix or /to w/o arguments.
>>>>>>>>>
>>>>>>>>> I'd even go for cd to change the node. The reason I didn't add it
>>>>>>>>> originally was 'directory' doesn't belong here. But cd is kind of habit
>>>>>>>>> for this kind of thing, so I could add it as an alias.
>>>>>>>>>
>>>>>>>>> Any objections or suggestions?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexey
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>> _______________________________________________
>>>>>>>> jboss-as7-dev mailing list
>>>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Principal Software Engineer
>>>>>>> JBoss by Red Hat
>>>>>>> _______________________________________________
>>>>>>> jboss-as7-dev mailing list
>>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>
>>>>>> /max
>>>>>> http://about.me/maxandersen
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>> --
>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>> Dimitris Andreadis
>>>>> Software Engineering Manager
>>>>> JBoss Application Server
>>>>> by Red Hat
>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>
>>>>> http://dandreadis.blogspot.com/
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> /max
> http://about.me/maxandersen
>
>
>

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat