Thanks for the clarification Brian.

On 12 Dec 2014, at 16:08, Brian Stansberry <brian.stansberry@redhat.com> wrote:

On 12/12/14, 2:14 AM, Heiko Braun wrote:

It’s hard to see the full context of this email thread, but here are two proposals I would like to comment on:

a) write attribute groups / or writing to attribute groups?
i.e :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})

b) nested attribute syntax
i.e. :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])


I think these are two different concerns, hence I am going to respond separately:

What’s the intention of proposal a)? Do you want to define new attribute groups this way or do you want to write values of attributes that belong to a specific group?


I don't propose to do a). The current proposal is this:

:write-attributes(attr1=5,attr2=true)

No relationship at all to attribute groups. The idea for it just evolved from an earlier suggestion in the thread for a).

This is simply a simpler syntax for a CLI batch that has two steps

batch
:write-attribute(name=attr1,value=5)
:write-attribute(name=att2,value=true)
run-batch

The batch/run-batch is just CLI syntax for grouping in a "composite" op, so the console could take advantage of the same thing if it wishes, eliminating some composites. The "composite" op then is only needed if the steps involve > 1 address, or if some step is something other than write-attribute.

I have similar problems with proposal b). What’s the intention behind the nested attribute syntax? A more convenient way to address complex attributes?

Yes, a more convenient way to address complex attributes.

The current proposal is not your b) though. There are two uses for nested-attribute syntax:

:write-attribute(name=bar[1].baz,value=true)

:write-attributes(attr1=5,bar[1].baz=true)

The latter is just syntactic sugar for a 2 step composite where the 2nd step is the former.

Or does this address attributes that belong to child resources?

No, not at all. The target of an operation is indicated by its address.














-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat