9:33 a.m.
Max, Emanuel and I discussed the usability aspects of the cli today. We
agreed on the following:
1) drop the '/' prefix for the commands;
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'
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
9:41 a.m.
On 03/07/2011 03:33 PM, Alexey Loubyansky 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;
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:50 a.m.
On 3/7/11 8:41 AM, Alexey Loubyansky wrote:
On 03/07/2011 03:33 PM, Alexey Loubyansky 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?
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
9:59 a.m.
On 03/07/2011 03:50 PM, Brian Stansberry wrote:
On 3/7/11 8:41 AM, Alexey Loubyansky wrote:
>
>
> On 03/07/2011 03:33 PM, Alexey Loubyansky 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?
Other than that question, what you describe here sounds fine (including
the 'cd' alias, which I know would be what I'd naturally use).
It's basically a switch. In the current impl commands require '/' as a
prefix and operations don't require anything. Here it's the opposite.
Operations performed at the current level (prefix address) would require
':'.
Operations performed at a deeper level than the current one (if they
need to specify additional address part) would start with './' then the
address part, then ':' + operation name.
Or, if you want to start from the root node, you'll have to start with '/'.
Commands won't require any prefix.
Alexey
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
11:50 a.m.
On 3/7/11 8:59 AM, Alexey Loubyansky wrote:
On 03/07/2011 03:50 PM, Brian Stansberry wrote:
> On 3/7/11 8:41 AM, Alexey Loubyansky wrote:
>>
>>
>> On 03/07/2011 03:33 PM, Alexey Loubyansky 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?
>
> Other than that question, what you describe here sounds fine (including
> the 'cd' alias, which I know would be what I'd naturally use).
It's basically a switch. In the current impl commands require '/' as a
prefix and operations don't require anything. Here it's the opposite.
Operations performed at the current level (prefix address) would require
':'.
Operations performed at a deeper level than the current one (if they
need to specify additional address part) would start with './' then the
address part, then ':' + operation name.
Or, if you want to start from the root node, you'll have to start with '/'.
Commands won't require any prefix.
Thanks. I realize now my question was stupid. "1) drop the '/' prefix
for the commands" tells me the answer pretty clearly!
Alexey
>>> 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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12:03 p.m.
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen
3:09 a.m.
New subject: Recent jboss-modules' JAXP-related changes and JAXB impl
Hi,
after the latest changes in jboss-modules for loading our own set of
jaxp factories, I'm seeing some regressions in the jbossws-cxf testsuite
against AS7:
java.lang.ClassCastException: __redirected.__TransformerFactory cannot
be cast to javax.xml.transform.sax.SAXTransformerFactory
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.createTransformerHandler(JAXBContextImpl.java:744)
at
com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader$State.<init>(DomLoader.java:63)
at
com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader.startElement(DomLoader.java:113)
at
com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:55)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:481)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:459)
at
com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:71)
at
com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:148)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:239)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:276)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:245)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:276)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:245)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:122)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:105)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:317)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:297)
at
org.apache.cxf.jaxws.spi.ProviderImpl.createW3CEndpointReference(ProviderImpl.java:311)
... 19 more
basically the JAXB impl expects the configured TransformerFactory to be
an instance of SAXTransformerFactory:
public static TransformerHandler createTransformerHandler() {
try {
synchronized(JAXBContextImpl.class) {
if(tf==null)
tf =
(SAXTransformerFactory)TransformerFactory.newInstance();
return tf.newTransformerHandler();
}
} catch (TransformerConfigurationException e) {
throw new Error(e); // impossible
}
}
Jason, what do we want to do? Implement SAXTransformerFactory too in
jboss-modules' __TransformerFactory ?
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
12:24 p.m.
New subject: Recent jboss-modules' JAXP-related changes and JAXB impl
Yes, I'll fix that. Thanks!
On 3/8/11 2:09 AM, Alessio Soldano wrote:
Hi,
after the latest changes in jboss-modules for loading our own set of
jaxp factories, I'm seeing some regressions in the jbossws-cxf testsuite
against AS7:
java.lang.ClassCastException: __redirected.__TransformerFactory cannot
be cast to javax.xml.transform.sax.SAXTransformerFactory
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.createTransformerHandler(JAXBContextImpl.java:744)
at
com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader$State.<init>(DomLoader.java:63)
at
com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader.startElement(DomLoader.java:113)
at
com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:55)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:481)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:459)
at
com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:71)
at
com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:148)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:239)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:276)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:245)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:276)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:245)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:122)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:105)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:317)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:297)
at
org.apache.cxf.jaxws.spi.ProviderImpl.createW3CEndpointReference(ProviderImpl.java:311)
... 19 more
basically the JAXB impl expects the configured TransformerFactory to be
an instance of SAXTransformerFactory:
public static TransformerHandler createTransformerHandler() {
try {
synchronized(JAXBContextImpl.class) {
if(tf==null)
tf =
(SAXTransformerFactory)TransformerFactory.newInstance();
return tf.newTransformerHandler();
}
} catch (TransformerConfigurationException e) {
throw new Error(e); // impossible
}
}
Jason, what do we want to do? Implement SAXTransformerFactory too in
jboss-modules' __TransformerFactory ?
Cheers
Alessio
--
Jason T. Greene
JBoss, a division of Red Hat
7:35 a.m.
+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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)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(a)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(a)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/
7:02 a.m.
A nice feature would be some history between cli sessions
On 9 Mar 2011, at 12:35, Dimitris Andreadis wrote:
+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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
7:10 a.m.
On 03/14/2011 11:02 AM, Kabir Khan wrote:
A nice feature would be some history between cli sessions
On 9 Mar 2011, at 12:35, Dimitris Andreadis wrote:
+1 - when I was using it the other day the first thing I tried was
pressing the up arrow to get the commands from my last session.
> +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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
7:14 a.m.
Also, getting rid of leading spaces when entering a command before parsing it, e.g.:
[/] connect
Unexpected command ' connect'. Type 'help' for the list of supported
commands.
[/]connect #works
[/] :add-system-property(name=foo,value=bar)
Unexpected command ' :add-system-property(name=foo,value=bar) '. Type
'help' for the list of supported commands.
On 14 Mar 2011, at 11:10, Darran Lofthouse wrote:
On 03/14/2011 11:02 AM, Kabir Khan wrote:
> A nice feature would be some history between cli sessions
> On 9 Mar 2011, at 12:35, Dimitris Andreadis wrote:
+1 - when I was using it the other day the first thing I tried was pressing the up arrow
to get the commands from my last session.
>
>> +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(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev(a)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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
6:08 p.m.
https://issues.jboss.org/browse/JBAS-8951
On 03/14/2011 12:14 PM, Kabir Khan wrote:
[/] connect
Unexpected command ' connect'. Type 'help' for the list of supported
commands.
[/]connect #works
[/] :add-system-property(name=foo,value=bar)
Unexpected command ' :add-system-property(name=foo,value=bar) '. Type
'help' for the list of supported commands.
12:35 p.m.
On 3/14/11 6:10 AM, Darran Lofthouse wrote:
On 03/14/2011 11:02 AM, Kabir Khan wrote:
> A nice feature would be some history between cli sessions
> On 9 Mar 2011, at 12:35, Dimitris Andreadis wrote:
+1 - when I was using it the other day the first thing I tried was
pressing the up arrow to get the commands from my last session.
We need to think about the security implications of this. Implementing
it basically means recording a history of commands in some store somewhere.
As an aside, for people playing with the CLI, you can actually bounce
the server, rebuild, do whatever, without closing the CLI process. If
the next time you type a command the server is available, it will all work.
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. ;)
>
>> +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(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev(a)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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
5:01 a.m.
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 ?
/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(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> jboss-as7-dev(a)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(a)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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen
10:13 a.m.
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(a)lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>> _______________________________________________
>>>>>>> jboss-as7-dev mailing list
>>>>>>> jboss-as7-dev(a)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(a)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(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)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(a)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
7:30 a.m.
A nice feature would be some history between cli sessions
agreed....
one thought though - is the intent to make the jboss-admin a full blown shell like
experience or is that
better served by other means ? i.e. integrate the cli into something like Seam Forge and
we benefit
from all the work in that shell...
...or using some clever bash/zsh magic to actually provide tab completion of AS7 commands
on a normal command line ?
/max
On 9 Mar 2011, at 12:35, Dimitris Andreadis wrote:
> +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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen
6:06 p.m.
I've created a Jira issue for this
https://issues.jboss.org/browse/JBAS-8950
On 03/14/2011 12:02 PM, Kabir Khan wrote:
A nice feature would be some history between cli sessions
On 9 Mar 2011, at 12:35, Dimitris Andreadis wrote:
> +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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4882
days inactive
4890
days old
17 comments
8 participants
participants (8)
-
Alessio Soldano -
Alexey Loubyansky -
Brian Stansberry -
Darran Lofthouse -
Dimitris Andreadis -
Jason T. Greene -
Kabir Khan -
Max Rydahl Andersen