[wildfly-dev] Management model attribute groups

[Brian Stansberry]

On 12/10/14, 10:02 AM, David M. Lloyd wrote:
> On 12/10/2014 08:21 AM, Brian Stansberry wrote:
>> On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote:
>>> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ?
>>
>> This is what I meant by
>>
>> "4) Low level management API
>>
>> The output of read-resource and read-resource-description is modified
>> such that attributes are sorted by group name and then by attribute name."
>>
>> I used the verb "sorted" though because I have no intent of modifying
>> the output structure by creating a level for the attribute group. That
>> would be an incompatible change in the output format and would obscure
>> the distinction between an attribute group and a complex attribute.
>
> FWIW I think this is a good distinction and a good approach.
>
>>> Is aliasing to be supported ?  What if I want to change the attribute group name ?
>>>
>>
>> Good question.
>>
>> Heiko, I don't think Emmanuel is talking about users changing this. We
>> use aliasing in other contexts as a mechanism for maintaining
>> compatibility. If something is poorly named (e.g. a bad resource address
>> name) we can fix it in a later release but also register an alias under
>> the old name to provide compatibility.
>>
>> I don't see how aliasing could work here. Only thing I can imagine is
>> using it in the ls -l output, such that the same attribute can appear >
>> 1 times, if it is associated with more than 1 group. I suppose a console
>> could do a similar thing, but I don't at all regard maintaining that
>> kind of compatibility in UI layout to be a requirement.
>>
>> I'm not sure how much we regard consistency in the ls -l output across
>> releases as being a requirement. I think of that as being an output
>> format for humans, not machines.
>>
>> Aliasing is an example of a reason for allowing an attribute to belong
>> to more than one group. There may be others. Perhaps as an aid to querying?
>
> I still feel strongly that we should look to real resource versioning as
> the proper solution here, though I realize there has not been a
> satisfactory resolution to this discussion.  But the longer we don't
> come to a resolution, the more (arguably questionable) tricks we have to
> pull to manage compatibility.
>

Agreed, at least re: we need to come to a resolution and that I don't 
want to add further tricks. So I don't see the aliasing use case as 
being a sufficient justification for allowing an attribute to be 
associated with > 1 group.

The (vague) querying notion is more interesting to me as a reason for 
allowing > 1 group. Really all I've described here is a form of tagging 
attributes. However, separating "tags" for querying from 
"attribute-group" which is specifically intended as a primary grouping 
clue for management UIs is IMO better.

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