[wildfly-dev] Management model attribute groups

[David M. Lloyd]

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.

-- 
- DML