1:28 p.m.
On 9/5/14, 12:42 PM, Jason Greene wrote:
The nice thing about expressing this in DMR as that you could have
one consistent data model vs nesting a bunch of different ones (DMR inside of CLI syntax
inside of XML syntax). We could also just add path support into the management API, just
parse the equivalent string.
{
“install-feature-list” => [“io”, “something-else"],
“tasks” => [
{
“address” => “/subsystem=io/worker=new-worker1”,
Regardless of this provisioning tool discussion, this is a good idea.
We have a bug to fix where passing "address" => "" (instead of
"address" => []) results in useless failure instead of a proper failure,
and the fix for that would likely involve some highly central point
where we validate the address param. That point could easily deal with
this too.
“operation” => “add”
},
{
“address” => “/subsystem=io/worker=new-worker2”,
“operation” => “add”
},
{
“address” => “/subsystem=io/worker=new-worker3”,
“operation” => “add”
}
]
}
Note that the CLI doesn’t hide DMR, in particular with an add operation. So the
difference will be pretty small imo.
On Sep 5, 2014, at 4:47 AM, Emmanuel Hugonnet <ehugonne(a)redhat.com> wrote:
> Can't the provisionning "build tool" convert the cli scripts in dmr in
building the feature pack ?
> Thus dmr would be the lingua franca of the provisionning itself.
> That might mean more rebuilding during the feature pack creation / configuration from
a user point of view.
> Emmanuel
>
> Le 05/09/2014 11:22, Kabir Khan a écrit :
>>
>> On 5 Sep 2014, at 09:59, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
>>
>>>
>>> On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas
<stuart.w.douglas(a)gmail.com> wrote:
>>> The problem with 3 is that for the most part users do not use DMR directly,
they use the CLI, and all our documentation reflects this. If we use DMR directly for this
it just one more thing that we require our users to learn.
>>>
>>>
>>> 90%+ of what users do in CLI is direct DMR.
>>> Things that CLI adds that are not part of native DMR are handlers like:
>>>
>>> - ls (instead of :read-resource),
>>> - reload (instead of :reload)
>>> - try,catch
>>> - batch*
>>> - if, else
>>> - clear, quit
>>> + some others
>>>
>>> but in general most of the commands people write are direct DMR.
>>> CLI only adds lots of usability features on top of them like tab completion.
>>>
>>> for example
>>> /subsystem=io/worker=new-worker:add()
>>> is 100% dmr operation.
>> Yes, but isn’t the issue that it is nicer for end users, who are used to the CLI
to write this rather than either using the serialized forms of the the DMR
representation, e.g. either (raw DMR)
>> {
>> "address" => [
>> ("subsystem" => "io"),
>> ("worker" => "new-worker")
>> ],
>> "operation" => “add”
>> }
>> or (JSON)
>> {
>> "address" : [
>> {
>> "subsystem" : "io"
>> },
>> {
>> "worker" : "new-worker"
>> }
>> ],
>> "operation" : "add"
>> }
>> is is a lot more usable to just be able to say
>> /subsystem=io/worker=new-worker:add()
>>
>>
>>>
>>> In any case if we go with WildFly embedded in CLI mode all this discussion is
non issue.
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat