[wildfly-dev] Management model attribute groups

[Jason Greene]

> On Dec 10, 2014, at 11:52 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> On 12/10/14, 11:44 AM, David M. Lloyd wrote:
>> Forgot to hit "reply to list" on this one.
>> 
>> On 12/10/2014 10:30 AM, Brian Stansberry wrote:
>>> On 12/10/14, 10:06 AM, David M. Lloyd wrote:
>>>> On 12/10/2014 09:52 AM, Brian Stansberry wrote:
>>>>> On 12/10/14, 9:22 AM, Kabir Khan wrote:
>>>>>> 
>>>>>>> On 9 Dec 2014, at 21:00, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>>>>> 
>>>>>>> Off and on we've had discussions around the idea of "attribute groups".
>>>>>>> We've got some use cases that are crying out for such a thing[1], so I'd
>>>>>>> like to propose doing something concrete but simple for these for WF 9,
>>>>>>> ideally in the next month.
>>>>>>> 
>>>>>>> A big part of my goal here is to ensure that whatever we do doesn't
>>>>>>> preclude something more advanced in any next generation management
>>>>>>> stuff, e.g. David's stuff.
>>>>>>> 
>>>>>>> PART I Concepts
>>>>>>> 
>>>>>>> 1) What is an attribute group?
>>>>>>> 
>>>>>>> The "attribute group" concept I propose is simply a collection of
>>>>>>> attributes associated with the same resource type that are independently
>>>>>>> configurable but are statically declared to be conceptually related. The
>>>>>>> group has a name, and members. The name provides a brief indication of
>>>>>>> the nature of the relationship.
>>>>>>> 
>>>>>>> The goal is to provide information to the user to help them better
>>>>>>> understand the relationship between attributes. In particular,
>>>>>>> management tools could use this information to visually present related
>>>>>>> attributes together, e.g. in a tab or other grouping widget in the web
>>>>>>> console.
>>>>>>> 
>>>>>>> 2) What isn't an attribute group?
>>>>>>> 
>>>>>>> Something relevant to writes.
>>>>>>> 
>>>>>>> 3) Why would I use a child resource instead of an attribute group?
>>>>>>> 
>>>>>>> Because the attributes control a discrete piece of functionality and you
>>>>>>> need to be able to turn that on or off as a unit. So you add/remove the
>>>>>>> resource.
>>>>>>> 
>>>>>>> 4) Why would I use a complex attribute with a bunch of fields instead of
>>>>>>> n>1 simple attributes in a group.
>>>>>>> 
>>>>>>> a) Because the attributes control a discrete piece of functionality and
>>>>>>> you need to be able to turn that off as a unit. So users can undefine
>>>>>>> the complex attribute.
>>>>>>> 
>>>>>>> b) Because it's a common use case that modifications to n>1 of the
>>>>>>> fields should be done atomically and you don't want to force users to
>>>>>>> use a CLI batch. So you let them use write-attribute and specify the
>>>>>>> value of all the fields.
>>>>>> Why not something along the lines of :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})?
>>>>>> Internally that could create a composite for us, giving complex attribute functionality while avoiding the messy resource descriptions
>>>>>> 
>>>>> 
>>>>> On the branch of the thread where I'm discussing with Tomaz, he raised
>>>>> the same idea, which I think is a good one. I think a "write-attributes"
>>>>> with no relationship to attribute-group makes more sense though.
>>>> 
>>>> I agree.  I have always felt that we should allow more than level of
>>>> grouping.
>>> 
>>> Did you mean "should NOT allow"?
>> 
>> No, I mean multiple levels _should_ be allowed, just with multiple
>> qualifiers.  Multiple attribute writing per resource _should_ be allowed
>> regardless of the depth or mixture of nesting.
>> 
>> I.e. I should be able to do something like :write-attributes({"foo" =
>> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard
>> necessary to deal with attribute group navigation.
>> 
> 
> Gotcha, and I agree. Thanks for clarifying.

Hmm that nested syntax is an orthogonal feature IMO. I think that requires a lot more thought, as its basically inventing another nested dmr-path grammar. Not to say that we shouldn’t have that I just see rabbit hole there.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat