[wildfly-dev] Management model attribute groups

[Brian Stansberry]

On 12/10/14, 11:01 AM, Brian Stansberry wrote:
> 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.
>

Hit send too early -- meant to say I'll try and think a lot about the 
versioning thing over the holidays when I'll be away from email/chat/etc 
and can actually focus on something big.

> 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