9 p.m.
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.
5) Why would I use an attribute group instead of a child resource?
Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.
6) Why would I use an attribute group instead a complex attribute?
Because the various attributes should be independently configurable. In
particular, wiping out the config for all of them by simply undefining
the complex attribute isn't appropriate.
PART II Proposed Work
1) The basics
We add a piece of metadata to the read-resource-description output for
an attribute. Name is 'attribute-group', value type is ModelType.STRING,
value is the name of the group, with 'undefined' allowed.
The group is simply the set of attributes that share the same string.
To implement this, we add public String
AttributeDefinition.getAttributeGroup() and add support for setting it
to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
2) XML parsing/marshalling
Modify PersistentResourceXMLDescription such that attributes in an
attribute group get persisted in their own child element, whose name is
the name of the group.
PersistentResourceXMLBuilder exposes a setter to allow users to turn
this on/off for that resource. Turning it off will allow the addition of
attribute group settings for a resource without requiring an immediate
corresponding xsd change.
3) Web console
HAL can make use of the additional metadata at its leisure, and as it
becomes available.
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.
5) CLI
I'm not clear on exactly what to do here, but my instinct is the output
of the 'ls -l' command should be modified. Probably add a GROUP column
to the right and sort the order of attributes by group and then by
attribute name.
PART III Other possible things to do
A :read-attribute-group(name=<groupname>) operation or an
"attribute-groups=[<groupname>*]" param to :read-resource, to make it
convenient to read a set of attributes without needing to read the
entire resource.
We could also consider adding an "attribute-groups" section to the
read-resource-description output, where a fuller i18n text description
of the meaning of the group could be written. If we do this we should
probably do it in WF 9 as it will likely add some sort of requirement to
subsystem authors that we expose right from the start.
If you're still awake, comments as always are appreciated.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
[1] For example, the JDKORB pull request at
https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
number of places where it seems like attribute groups are a better fit.
11:41 p.m.
This proposal is a great idea. Let’s do it :)
On Dec 9, 2014, at 2:00 PM, Brian Stansberry
<brian.stansberry(a)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.
5) Why would I use an attribute group instead of a child resource?
Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.
6) Why would I use an attribute group instead a complex attribute?
Because the various attributes should be independently configurable. In
particular, wiping out the config for all of them by simply undefining
the complex attribute isn't appropriate.
PART II Proposed Work
1) The basics
We add a piece of metadata to the read-resource-description output for
an attribute. Name is 'attribute-group', value type is ModelType.STRING,
value is the name of the group, with 'undefined' allowed.
The group is simply the set of attributes that share the same string.
To implement this, we add public String
AttributeDefinition.getAttributeGroup() and add support for setting it
to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
2) XML parsing/marshalling
Modify PersistentResourceXMLDescription such that attributes in an
attribute group get persisted in their own child element, whose name is
the name of the group.
PersistentResourceXMLBuilder exposes a setter to allow users to turn
this on/off for that resource. Turning it off will allow the addition of
attribute group settings for a resource without requiring an immediate
corresponding xsd change.
3) Web console
HAL can make use of the additional metadata at its leisure, and as it
becomes available.
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.
5) CLI
I'm not clear on exactly what to do here, but my instinct is the output
of the 'ls -l' command should be modified. Probably add a GROUP column
to the right and sort the order of attributes by group and then by
attribute name.
PART III Other possible things to do
A :read-attribute-group(name=<groupname>) operation or an
"attribute-groups=[<groupname>*]" param to :read-resource, to make it
convenient to read a set of attributes without needing to read the
entire resource.
We could also consider adding an "attribute-groups" section to the
read-resource-description output, where a fuller i18n text description
of the meaning of the group could be written. If we do this we should
probably do it in WF 9 as it will likely add some sort of requirement to
subsystem authors that we expose right from the start.
If you're still awake, comments as always are appreciated.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
[1] For example, the JDKORB pull request at
https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
number of places where it seems like attribute groups are a better fit.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
10:59 a.m.
Maybe we should also group attributes by their attribute group names instead of displaying
them per natural sorting ?
Is aliasing to be supported ? What if I want to change the attribute group name ?
Emmanuel
Le 09/12/2014 21:00, Brian Stansberry a écrit :
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.
5) Why would I use an attribute group instead of a child resource?
Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.
6) Why would I use an attribute group instead a complex attribute?
Because the various attributes should be independently configurable. In
particular, wiping out the config for all of them by simply undefining
the complex attribute isn't appropriate.
PART II Proposed Work
1) The basics
We add a piece of metadata to the read-resource-description output for
an attribute. Name is 'attribute-group', value type is ModelType.STRING,
value is the name of the group, with 'undefined' allowed.
The group is simply the set of attributes that share the same string.
To implement this, we add public String
AttributeDefinition.getAttributeGroup() and add support for setting it
to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
2) XML parsing/marshalling
Modify PersistentResourceXMLDescription such that attributes in an
attribute group get persisted in their own child element, whose name is
the name of the group.
PersistentResourceXMLBuilder exposes a setter to allow users to turn
this on/off for that resource. Turning it off will allow the addition of
attribute group settings for a resource without requiring an immediate
corresponding xsd change.
3) Web console
HAL can make use of the additional metadata at its leisure, and as it
becomes available.
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.
5) CLI
I'm not clear on exactly what to do here, but my instinct is the output
of the 'ls -l' command should be modified. Probably add a GROUP column
to the right and sort the order of attributes by group and then by
attribute name.
PART III Other possible things to do
A :read-attribute-group(name=<groupname>) operation or an
"attribute-groups=[<groupname>*]" param to :read-resource, to make it
convenient to read a set of attributes without needing to read the
entire resource.
We could also consider adding an "attribute-groups" section to the
read-resource-description output, where a fuller i18n text description
of the meaning of the group could be written. If we do this we should
probably do it in WF 9 as it will likely add some sort of requirement to
subsystem authors that we expose right from the start.
If you're still awake, comments as always are appreciated.
1:26 p.m.
Changing group names is not user space Api. Users can map internal names to custom titles,
if needed.
Am 10.12.2014 um 10:59 schrieb Emmanuel Hugonnet
<ehugonne(a)redhat.com>:
Maybe we should also group attributes by their attribute group names instead of
displaying them per natural sorting ?
Is aliasing to be supported ? What if I want to change the attribute group name ?
Emmanuel
Le 09/12/2014 21:00, Brian Stansberry a écrit :
> 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.
>
> 5) Why would I use an attribute group instead of a child resource?
>
> Because requiring users to add a child resource just to set a bunch of
> values that are really part of the config of the parent resource forces
> them to use a CLI batch to correctly configure the parent resource.
>
> 6) Why would I use an attribute group instead a complex attribute?
>
> Because the various attributes should be independently configurable. In
> particular, wiping out the config for all of them by simply undefining
> the complex attribute isn't appropriate.
>
> PART II Proposed Work
>
> 1) The basics
>
> We add a piece of metadata to the read-resource-description output for
> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
> value is the name of the group, with 'undefined' allowed.
>
> The group is simply the set of attributes that share the same string.
>
> To implement this, we add public String
> AttributeDefinition.getAttributeGroup() and add support for setting it
> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>
> 2) XML parsing/marshalling
>
> Modify PersistentResourceXMLDescription such that attributes in an
> attribute group get persisted in their own child element, whose name is
> the name of the group.
>
> PersistentResourceXMLBuilder exposes a setter to allow users to turn
> this on/off for that resource. Turning it off will allow the addition of
> attribute group settings for a resource without requiring an immediate
> corresponding xsd change.
>
> 3) Web console
>
> HAL can make use of the additional metadata at its leisure, and as it
> becomes available.
>
> 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.
>
> 5) CLI
>
> I'm not clear on exactly what to do here, but my instinct is the output
> of the 'ls -l' command should be modified. Probably add a GROUP column
> to the right and sort the order of attributes by group and then by
> attribute name.
>
> PART III Other possible things to do
>
> A :read-attribute-group(name=<groupname>) operation or an
> "attribute-groups=[<groupname>*]" param to :read-resource, to make it
> convenient to read a set of attributes without needing to read the
> entire resource.
>
> We could also consider adding an "attribute-groups" section to the
> read-resource-description output, where a fuller i18n text description
> of the meaning of the group could be written. If we do this we should
> probably do it in WF 9 as it will likely add some sort of requirement to
> subsystem authors that we expose right from the start.
>
>
> If you're still awake, comments as always are appreciated.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:21 p.m.
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.
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?
Emmanuel
Le 09/12/2014 21:00, Brian Stansberry a écrit :
> 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.
>
> 5) Why would I use an attribute group instead of a child resource?
>
> Because requiring users to add a child resource just to set a bunch of
> values that are really part of the config of the parent resource forces
> them to use a CLI batch to correctly configure the parent resource.
>
> 6) Why would I use an attribute group instead a complex attribute?
>
> Because the various attributes should be independently configurable. In
> particular, wiping out the config for all of them by simply undefining
> the complex attribute isn't appropriate.
>
> PART II Proposed Work
>
> 1) The basics
>
> We add a piece of metadata to the read-resource-description output for
> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
> value is the name of the group, with 'undefined' allowed.
>
> The group is simply the set of attributes that share the same string.
>
> To implement this, we add public String
> AttributeDefinition.getAttributeGroup() and add support for setting it
> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>
> 2) XML parsing/marshalling
>
> Modify PersistentResourceXMLDescription such that attributes in an
> attribute group get persisted in their own child element, whose name is
> the name of the group.
>
> PersistentResourceXMLBuilder exposes a setter to allow users to turn
> this on/off for that resource. Turning it off will allow the addition of
> attribute group settings for a resource without requiring an immediate
> corresponding xsd change.
>
> 3) Web console
>
> HAL can make use of the additional metadata at its leisure, and as it
> becomes available.
>
> 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.
>
> 5) CLI
>
> I'm not clear on exactly what to do here, but my instinct is the output
> of the 'ls -l' command should be modified. Probably add a GROUP column
> to the right and sort the order of attributes by group and then by
> attribute name.
>
> PART III Other possible things to do
>
> A :read-attribute-group(name=<groupname>) operation or an
> "attribute-groups=[<groupname>*]" param to :read-resource, to make
it
> convenient to read a set of attributes without needing to read the
> entire resource.
>
> We could also consider adding an "attribute-groups" section to the
> read-resource-description output, where a fuller i18n text description
> of the meaning of the group could be written. If we do this we should
> probably do it in WF 9 as it will likely add some sort of requirement to
> subsystem authors that we expose right from the start.
>
>
> If you're still awake, comments as always are appreciated.
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3:23 p.m.
On Tue, Dec 9, 2014 at 9:00 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
5) Why would I use an attribute group instead of a child resource?
Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.
One thing that I am not sure about this is, how do we do validation for
things like this?
Simple example would be "required" validation for attribute group.
You want to enforce few attributes that are part of the group to be
required.
but on other hand you don't want to enforce them as part of resource:add
operation.
as they are only "required" when you are editing / adding attribute group.
With current code we enforce required for all attributes on a resource that
is being added.
Which is bit inconvenient for when we have attribute groups and want to do
it bit differently.
So question is should we support selective validation based on groups or
not?
--
tomaz
3:29 p.m.
On 12/9/14, 4:41 PM, Jason Greene wrote:
This proposal is a great idea. Let’s do it :)
I can probably have a branch with the "Proposed Work" bit, excluding the
CLI ls -l thing, done today or tomorrow. It went quicker than I thought.
But the more important part is any discussion here. The CLI ls -l thing
I don't want to code yet because I don't have a strong feeling about
that solution.
> On Dec 9, 2014, at 2:00 PM, Brian Stansberry
<brian.stansberry(a)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.
>
> 5) Why would I use an attribute group instead of a child resource?
>
> Because requiring users to add a child resource just to set a bunch of
> values that are really part of the config of the parent resource forces
> them to use a CLI batch to correctly configure the parent resource.
>
> 6) Why would I use an attribute group instead a complex attribute?
>
> Because the various attributes should be independently configurable. In
> particular, wiping out the config for all of them by simply undefining
> the complex attribute isn't appropriate.
>
> PART II Proposed Work
>
> 1) The basics
>
> We add a piece of metadata to the read-resource-description output for
> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
> value is the name of the group, with 'undefined' allowed.
>
> The group is simply the set of attributes that share the same string.
>
> To implement this, we add public String
> AttributeDefinition.getAttributeGroup() and add support for setting it
> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>
> 2) XML parsing/marshalling
>
> Modify PersistentResourceXMLDescription such that attributes in an
> attribute group get persisted in their own child element, whose name is
> the name of the group.
>
> PersistentResourceXMLBuilder exposes a setter to allow users to turn
> this on/off for that resource. Turning it off will allow the addition of
> attribute group settings for a resource without requiring an immediate
> corresponding xsd change.
>
> 3) Web console
>
> HAL can make use of the additional metadata at its leisure, and as it
> becomes available.
>
> 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.
>
> 5) CLI
>
> I'm not clear on exactly what to do here, but my instinct is the output
> of the 'ls -l' command should be modified. Probably add a GROUP column
> to the right and sort the order of attributes by group and then by
> attribute name.
>
> PART III Other possible things to do
>
> A :read-attribute-group(name=<groupname>) operation or an
> "attribute-groups=[<groupname>*]" param to :read-resource, to make
it
> convenient to read a set of attributes without needing to read the
> entire resource.
>
> We could also consider adding an "attribute-groups" section to the
> read-resource-description output, where a fuller i18n text description
> of the meaning of the group could be written. If we do this we should
> probably do it in WF 9 as it will likely add some sort of requirement to
> subsystem authors that we expose right from the start.
>
>
> If you're still awake, comments as always are appreciated.
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
>
> [1] For example, the JDKORB pull request at
> https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
> number of places where it seems like attribute groups are a better fit.
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3:45 p.m.
On 12/10/14, 8:23 AM, Tomaž Cerar wrote:
On Tue, Dec 9, 2014 at 9:00 PM, Brian Stansberry
<brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
5) Why would I use an attribute group instead of a child resource?
Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.
One thing that I am not sure about this is, how do we do validation for
things like this?
Simple example would be "required" validation for attribute group.
You want to enforce few attributes that are part of the group to be
required.
but on other hand you don't want to enforce them as part of resource:add
operation.
as they are only "required" when you are editing / adding attribute group.
With current code we enforce required for all attributes on a resource
that is being added.
Which is bit inconvenient for when we have attribute groups and want to
do it bit differently.
So question is should we support selective validation based on groups or
not?
This sounds more like a complex attribute or a child resource. The
attributes control a discrete piece of functionality and
you need to be able to turn that on/off as a unit. The attributes are
required if that functionality is turned on.
--
tomaz
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
4:05 p.m.
On Wed, Dec 10, 2014 at 3:45 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
This sounds more like a complex attribute or a child resource. The
attributes control a discrete piece of functionality and
you need to be able to turn that on/off as a unit. The attributes are
required if that functionality is turned on.
Agreed, but how do you handle scenario where you just add resource that has
30 attributes all in attribute groups.
You call :add() without any parameters as you plan to add/edit attributes
that are part of attribute group in next step.
you than call
:write-attribute(name=non-require-attribute-that-is-part-of-group-that-has-few-required,
value="some-value")
and this should fail, as attribute is part of attribute group.
It is a tricky thing to address, as we have not atomic way to write/update
more than one attribute at ones.
maybe have extra operation to do
write-attribute-group(name="first-attribute-group",
attr1=value,attr2=value) similar to :add semantics.
otherwise I don't see any good way to do atomic updates of whole attribute
group.
4:22 p.m.
On 9 Dec 2014, at 21:00, Brian Stansberry
<brian.stansberry(a)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
5) Why would I use an attribute group instead of a child resource?
Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.
6) Why would I use an attribute group instead a complex attribute?
Because the various attributes should be independently configurable. In
particular, wiping out the config for all of them by simply undefining
the complex attribute isn't appropriate.
PART II Proposed Work
1) The basics
We add a piece of metadata to the read-resource-description output for
an attribute. Name is 'attribute-group', value type is ModelType.STRING,
value is the name of the group, with 'undefined' allowed.
The group is simply the set of attributes that share the same string.
To implement this, we add public String
AttributeDefinition.getAttributeGroup() and add support for setting it
to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
2) XML parsing/marshalling
Modify PersistentResourceXMLDescription such that attributes in an
attribute group get persisted in their own child element, whose name is
the name of the group.
PersistentResourceXMLBuilder exposes a setter to allow users to turn
this on/off for that resource. Turning it off will allow the addition of
attribute group settings for a resource without requiring an immediate
corresponding xsd change.
3) Web console
HAL can make use of the additional metadata at its leisure, and as it
becomes available.
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.
5) CLI
I'm not clear on exactly what to do here, but my instinct is the output
of the 'ls -l' command should be modified. Probably add a GROUP column
to the right and sort the order of attributes by group and then by
attribute name.
PART III Other possible things to do
A :read-attribute-group(name=<groupname>) operation or an
"attribute-groups=[<groupname>*]" param to :read-resource, to make it
convenient to read a set of attributes without needing to read the
entire resource.
We could also consider adding an "attribute-groups" section to the
read-resource-description output, where a fuller i18n text description
of the meaning of the group could be written. If we do this we should
probably do it in WF 9 as it will likely add some sort of requirement to
subsystem authors that we expose right from the start.
If you're still awake, comments as always are appreciated.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
[1] For example, the JDKORB pull request at
https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
number of places where it seems like attribute groups are a better fit.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:51 p.m.
On 12/10/14, 9:05 AM, Tomaž Cerar wrote:
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
On Wed, Dec 10, 2014 at 3:45 PM, Brian Stansberry
<brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
This sounds more like a complex attribute or a child resource. The
attributes control a discrete piece of functionality and
you need to be able to turn that on/off as a unit. The attributes
are required if that functionality is turned on.
Agreed, but how do you handle scenario where you just add resource that
has 30 attributes all in attribute groups.
You call :add() without any parameters as you plan to add/edit
attributes that are part of attribute group in next step.
you than call
:write-attribute(name=non-require-attribute-that-is-part-of-group-that-has-few-required,
value="some-value")
and this should fail, as attribute is part of attribute group.
You use a batch if it's important to you to format your request into
separate lines. Or you just include all the params and use the line
separator to break your add up into multiple lines and save a lot of typing.
(I'm not really arguing against you ^^^, just pointing out ways to do
things in case readers are not aware.)
It is a tricky thing to address, as we have not atomic way to
write/update more than one attribute at ones.
maybe have extra operation to do
write-attribute-group(name="first-attribute-group",
attr1=value,attr2=value) similar to :add semantics.
otherwise I don't see any good way to do atomic updates of whole
attribute group.
Ok, I'll add this to the "Other possible things to do" bit. Thanks for
the input. :)
I think "write-attributes(attr1=value,attr2=value)" makes more sense
though. This is really syntactic sugar around updating multiple
attribute in one op, not requiring client-side creation of a composite.
There's no need to tie the concept to the attribute-group notion.
4:52 p.m.
On 12/10/14, 9:22 AM, Kabir Khan wrote:
> On 9 Dec 2014, at 21:00, Brian Stansberry <brian.stansberry(a)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.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
5:02 p.m.
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
5:06 p.m.
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(a)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. Having a special operation that "knows about" attribute
groups in some special way is thus precluded; simply having a multiple
"write-attributes" fits in nicely with the concept that a resource is
actually our basic atomic unit of granularity.
--
- DML
5:18 p.m.
On Wed, Dec 10, 2014 at 4:52 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
On 12/10/14, 9:22 AM, Kabir Khan wrote:
>
>> On 9 Dec 2014, at 21:00, Brian Stansberry <brian.stansberry(a)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.
In your preamble you said:
[...] 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. [...]
Doesn't it clash with your last thought?
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
5:30 p.m.
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(a)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"?
Having a special operation that "knows about" attribute
groups in some special way is thus precluded; simply having a multiple
"write-attributes" fits in nicely with the concept that a resource is
actually our basic atomic unit of granularity.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
5:39 p.m.
On 12/10/14, 10:18 AM, Dev Ops wrote:
On Wed, Dec 10, 2014 at 4:52 PM, Brian Stansberry
<brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
On 12/10/14, 9:22 AM, Kabir Khan wrote:
>
>> On 9 Dec 2014, at 21:00, Brian Stansberry
<brian.stansberry(a)redhat.com <mailto:brian.stansberry@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.
In your preamble you said:
[...] 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. [...]
Doesn't it clash with your last thought?
I don't think so. Attributes can be independently configurable, but it's
still valid for a user to want to change several of them in a single
atomic operation. Users can do that via a CLI batch, which internally
uses the low-level "composite" operation (which is used by the console
as well). This "write-attributes" op is just a different syntax to
atomically update several things. It's much less verbose than doing the
same thing with batch/composite but is limited to a single use case of
changing several attributes on the same resource.
Of course if you want to change several attributes each on several
different resources you could use batch/composite in combination with
write-attributes and save quite a bit of typing.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
6:01 p.m.
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
6:03 p.m.
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
6:44 p.m.
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(a)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.
--
- DML
6:52 p.m.
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(a)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.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
11:53 p.m.
On 12/10/14, 8:29 AM, Brian Stansberry wrote:
On 12/9/14, 4:41 PM, Jason Greene wrote:
> This proposal is a great idea. Let’s do it :)
>
I can probably have a branch with the "Proposed Work" bit, excluding the
CLI ls -l thing, done today or tomorrow. It went quicker than I thought.
https://github.com/wildfly/wildfly-core/pull/391
https://issues.jboss.org/browse/WFCORE-457
But the more important part is any discussion here. The CLI ls -l
thing
I don't want to code yet because I don't have a strong feeling about
that solution.
>> On Dec 9, 2014, at 2:00 PM, Brian Stansberry <brian.stansberry(a)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.
>>
>> 5) Why would I use an attribute group instead of a child resource?
>>
>> Because requiring users to add a child resource just to set a bunch of
>> values that are really part of the config of the parent resource forces
>> them to use a CLI batch to correctly configure the parent resource.
>>
>> 6) Why would I use an attribute group instead a complex attribute?
>>
>> Because the various attributes should be independently configurable. In
>> particular, wiping out the config for all of them by simply undefining
>> the complex attribute isn't appropriate.
>>
>> PART II Proposed Work
>>
>> 1) The basics
>>
>> We add a piece of metadata to the read-resource-description output for
>> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
>> value is the name of the group, with 'undefined' allowed.
>>
>> The group is simply the set of attributes that share the same string.
>>
>> To implement this, we add public String
>> AttributeDefinition.getAttributeGroup() and add support for setting it
>> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>>
>> 2) XML parsing/marshalling
>>
>> Modify PersistentResourceXMLDescription such that attributes in an
>> attribute group get persisted in their own child element, whose name is
>> the name of the group.
>>
>> PersistentResourceXMLBuilder exposes a setter to allow users to turn
>> this on/off for that resource. Turning it off will allow the addition of
>> attribute group settings for a resource without requiring an immediate
>> corresponding xsd change.
>>
>> 3) Web console
>>
>> HAL can make use of the additional metadata at its leisure, and as it
>> becomes available.
>>
>> 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.
>>
>> 5) CLI
>>
>> I'm not clear on exactly what to do here, but my instinct is the output
>> of the 'ls -l' command should be modified. Probably add a GROUP column
>> to the right and sort the order of attributes by group and then by
>> attribute name.
>>
>> PART III Other possible things to do
>>
>> A :read-attribute-group(name=<groupname>) operation or an
>> "attribute-groups=[<groupname>*]" param to :read-resource, to
make it
>> convenient to read a set of attributes without needing to read the
>> entire resource.
>>
>> We could also consider adding an "attribute-groups" section to the
>> read-resource-description output, where a fuller i18n text description
>> of the meaning of the group could be written. If we do this we should
>> probably do it in WF 9 as it will likely add some sort of requirement to
>> subsystem authors that we expose right from the start.
>>
>>
>> If you're still awake, comments as always are appreciated.
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>>
>> [1] For example, the JDKORB pull request at
>> https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
>> number of places where it seems like attribute groups are a better fit.
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:06 a.m.
https://issues.jboss.org/browse/WFCORE-458 for the read-attribute-group
bits.
On 12/10/14, 1:04 AM, Heiko Braun wrote:
+1 i am all for it. Including read-attribute-group(). But i would as
well add a read-attribute-group-names() operation to complete the picture.
> Am 09.12.2014 um 21:00 schrieb Brian Stansberry <brian.stansberry(a)redhat.com>:
>
> read-attribute-group
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:14 a.m.
On Dec 10, 2014, at 11:52 AM, Brian Stansberry
<brian.stansberry(a)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(a)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
12:27 a.m.
On 12/10/14, 5:14 PM, Jason Greene wrote:
> On Dec 10, 2014, at 11:52 AM, Brian Stansberry <brian.stansberry(a)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(a)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.
Weird timing. I'm writing the JIRA for "write-attributes", trying to be
precise, and I just now hit that rabbit hole.
We already have the syntax, but it's used in the *value* of the "name"
parameter to "write-attribute". Here we are using it in the parameter
*name*. That makes it impractical to have a proper list of
request-properties (aka params) in the read-operation-description output
for the write-attributes op registered against a given address. Without
that syntax, the parameter list would look much like the parameters for
the resource's "add" operation.
Further down the rabbit hole, thinking about this earlier I realized the
read-operation-description output for the "write-attribute" operation is
not as good as it could be. For any given resource, the description of
the "name" parameter could/should include the legal values, i.e. the
names of the writable attributes. We don't do that, and now we really can't.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:34 a.m.
On 12/10/2014 05:27 PM, Brian Stansberry wrote:
On 12/10/14, 5:14 PM, Jason Greene wrote:
>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
>> On 12/10/14, 11:44 AM, David M. Lloyd wrote:
>>> 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.
Weird timing. I'm writing the JIRA for "write-attributes", trying to be
precise, and I just now hit that rabbit hole.
We already have the syntax, but it's used in the *value* of the "name"
parameter to "write-attribute". Here we are using it in the parameter
*name*. That makes it impractical to have a proper list of
request-properties (aka params) in the read-operation-description output
for the write-attributes op registered against a given address.
Why does it make a difference? The attribute names would be "a.b.c"
instead of just "a", but I don't see that as an impracticality.
Withoutthat syntax, the parameter list would look much like the
parameters for
the resource's "add" operation.
Why is that a problem? It's essentially the same thing in most cases,
isn't it?
Further down the rabbit hole, thinking about this earlier I realized
the
read-operation-description output for the "write-attribute" operation is
not as good as it could be. For any given resource, the description of
the "name" parameter could/should include the legal values, i.e. the
names of the writable attributes. We don't do that, and now we really can't.
Why not?
--
- DML
12:35 a.m.
On 12/10/14, 5:27 PM, Brian Stansberry wrote:
On 12/10/14, 5:14 PM, Jason Greene wrote:
>
>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry
>> <brian.stansberry(a)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(a)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.
>
Weird timing. I'm writing the JIRA for "write-attributes", trying to be
precise, and I just now hit that rabbit hole.
We already have the syntax, but it's used in the *value* of the "name"
parameter to "write-attribute". Here we are using it in the parameter
*name*. That makes it impractical to have a proper list of
request-properties (aka params) in the read-operation-description output
for the write-attributes op registered against a given address. Without
that syntax, the parameter list would look much like the parameters for
the resource's "add" operation.
Further down the rabbit hole, thinking about this earlier I realized the
read-operation-description output for the "write-attribute" operation is
not as good as it could be. For any given resource, the description of
the "name" parameter could/should include the legal values, i.e. the
names of the writable attributes. We don't do that, and now we really
can't.
I gave up writing up the JIRA, as I want it to be precise and it can't
be precise enough until we have a good solution to this question. An
ugly one is:
:write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])
That's a lot more confusing and verbose than
:write-attributes(foo=123,bar.baz.zap=hello)
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:37 a.m.
On 12/10/2014 05:35 PM, Brian Stansberry wrote:
On 12/10/14, 5:27 PM, Brian Stansberry wrote:
> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>
>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry
>>> <brian.stansberry(a)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(a)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.
>>
>
> Weird timing. I'm writing the JIRA for "write-attributes", trying to
be
> precise, and I just now hit that rabbit hole.
>
> We already have the syntax, but it's used in the *value* of the "name"
> parameter to "write-attribute". Here we are using it in the parameter
> *name*. That makes it impractical to have a proper list of
> request-properties (aka params) in the read-operation-description output
> for the write-attributes op registered against a given address. Without
> that syntax, the parameter list would look much like the parameters for
> the resource's "add" operation.
>
> Further down the rabbit hole, thinking about this earlier I realized the
> read-operation-description output for the "write-attribute" operation is
> not as good as it could be. For any given resource, the description of
> the "name" parameter could/should include the legal values, i.e. the
> names of the writable attributes. We don't do that, and now we really
> can't.
>
I gave up writing up the JIRA, as I want it to be precise and it can't
be precise enough until we have a good solution to this question. An
ugly one is:
:write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])
That's a lot more confusing and verbose than
:write-attributes(foo=123,bar.baz.zap=hello)
I guess I missed a beat; why can't we do the latter? Is it because of
the way we describe operations? IMO this operation should be on an
equal footing with adding resources and we should have a uniform means
to describe it as such.
--
- DML
12:38 a.m.
On 12/10/14, 5:34 PM, David M. Lloyd wrote:
On 12/10/2014 05:27 PM, Brian Stansberry wrote:
> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
>>> On 12/10/14, 11:44 AM, David M. Lloyd wrote:
>>>> 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.
>
> Weird timing. I'm writing the JIRA for "write-attributes", trying to
be
> precise, and I just now hit that rabbit hole.
>
> We already have the syntax, but it's used in the *value* of the "name"
> parameter to "write-attribute". Here we are using it in the parameter
> *name*. That makes it impractical to have a proper list of
> request-properties (aka params) in the read-operation-description output
> for the write-attributes op registered against a given address.
Why does it make a difference? The attribute names would be "a.b.c"
instead of just "a", but I don't see that as an impracticality.
IIRC the syntax also allows list indexing, so it's not static.
> Withoutthat syntax, the parameter list would look much like the
parameters for
> the resource's "add" operation.
Why is that a problem? It's essentially the same thing in most cases,
isn't it?
> Further down the rabbit hole, thinking about this earlier I realized the
> read-operation-description output for the "write-attribute" operation is
> not as good as it could be. For any given resource, the description of
> the "name" parameter could/should include the legal values, i.e. the
> names of the writable attributes. We don't do that, and now we really can't.
Why not?
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
1:02 a.m.
On 12/10/14, 5:37 PM, David M. Lloyd wrote:
On 12/10/2014 05:35 PM, Brian Stansberry wrote:
> On 12/10/14, 5:27 PM, Brian Stansberry wrote:
>> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>>
>>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry
>>>> <brian.stansberry(a)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(a)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.
>>>
>>
>> Weird timing. I'm writing the JIRA for "write-attributes", trying
to be
>> precise, and I just now hit that rabbit hole.
>>
>> We already have the syntax, but it's used in the *value* of the
"name"
>> parameter to "write-attribute". Here we are using it in the parameter
>> *name*. That makes it impractical to have a proper list of
>> request-properties (aka params) in the read-operation-description output
>> for the write-attributes op registered against a given address. Without
>> that syntax, the parameter list would look much like the parameters for
>> the resource's "add" operation.
>>
>> Further down the rabbit hole, thinking about this earlier I realized the
>> read-operation-description output for the "write-attribute" operation
is
>> not as good as it could be. For any given resource, the description of
>> the "name" parameter could/should include the legal values, i.e. the
>> names of the writable attributes. We don't do that, and now we really
>> can't.
>>
>
> I gave up writing up the JIRA, as I want it to be precise and it can't
> be precise enough until we have a good solution to this question. An
> ugly one is:
>
> :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])
>
> That's a lot more confusing and verbose than
>
> :write-attributes(foo=123,bar.baz.zap=hello)
I guess I missed a beat; why can't we do the latter? Is it because of
the way we describe operations? IMO this operation should be on an
equal footing with adding resources and we should have a uniform means
to describe it as such.
We describe the parameters to operations, including their names, and for
all cases up to now those are easily and statically known. The CLI
validates the parameter names used in low-level ops against the description.
This can be solved by analyzing any complex attributes and outputing all
valid paths, using syntax like [] or [?] or [*] to indicate path
segments that represent elements in a list. We don't allow '.', '[' or
']' in attribute/field names, so the presence of the [ is enough to
indicate that a list element is being described; the remaining ']', '?]'
or '*]' are just to improve readability. I prefer a simple '[]'.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
2:42 p.m.
On Thu, Dec 11, 2014 at 12:37 AM, David M. Lloyd <david.lloyd(a)redhat.com>
wrote:
I guess I missed a beat; why can't we do the latter? Is it
because of
the way we describe operations? IMO this operation should be on an
equal footing with adding resources and we should have a uniform means
to describe it as such.
I think what you are looking for is being addressed as part of different
issue.
We had discussion about it few months back.
The proposed behavior is described here
https://gist.github.com/ctomc/91055a6f4e7502dcd130
The first part about collections operations is already done the extended
write/read-attribute syntax not yet.
Jira for it https://issues.jboss.org/browse/WFCORE-460
Is this what you are aiming for?
as :write-attributes operation we are talking about is different thing,
just allowing us to atomically update more than
one attribute. The extended manipulation syntax would also apply to this.
10:09 p.m.
New subject: A write-attributes op, and dealing with complex attribute paths
This is a separate topic from the previous thread, so renaming.
Bottom-post below...
On 12/10/14, 6:02 PM, Brian Stansberry wrote:
On 12/10/14, 5:37 PM, David M. Lloyd wrote:
> On 12/10/2014 05:35 PM, Brian Stansberry wrote:
>> On 12/10/14, 5:27 PM, Brian Stansberry wrote:
>>> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>>>>> 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:
>>>>>>>>>> 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.
>>>>>>
>>>>
>>>> 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.
>>>>
>>>
>>> Weird timing. I'm writing the JIRA for "write-attributes",
trying to be
>>> precise, and I just now hit that rabbit hole.
>>>
>>> We already have the syntax, but it's used in the *value* of the
"name"
>>> parameter to "write-attribute". Here we are using it in the
parameter
>>> *name*. That makes it impractical to have a proper list of
>>> request-properties (aka params) in the read-operation-description output
>>> for the write-attributes op registered against a given address. Without
>>> that syntax, the parameter list would look much like the parameters for
>>> the resource's "add" operation.
>>>
>>> Further down the rabbit hole, thinking about this earlier I realized the
>>> read-operation-description output for the "write-attribute"
operation is
>>> not as good as it could be. For any given resource, the description of
>>> the "name" parameter could/should include the legal values, i.e.
the
>>> names of the writable attributes. We don't do that, and now we really
>>> can't.
>>>
>>
>> I gave up writing up the JIRA, as I want it to be precise and it can't
>> be precise enough until we have a good solution to this question. An
>> ugly one is:
>>
>>
:write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])
>>
>> That's a lot more confusing and verbose than
>>
>> :write-attributes(foo=123,bar.baz.zap=hello)
>
> I guess I missed a beat; why can't we do the latter? Is it because of
> the way we describe operations? IMO this operation should be on an
> equal footing with adding resources and we should have a uniform means
> to describe it as such.
>
We describe the parameters to operations, including their names, and for
all cases up to now those are easily and statically known. The CLI
validates the parameter names used in low-level ops against the description.
This can be solved by analyzing any complex attributes and outputing all
valid paths, using syntax like [] or [?] or [*] to indicate path
segments that represent elements in a list. We don't allow '.', '['
or
']' in attribute/field names, so the presence of the [ is enough to
indicate that a list element is being described; the remaining ']', '?]'
or '*]' are just to improve readability. I prefer a simple '[]'.
IMHO my post ^^^ is wrong-headed. I don't think we should try and
describe this kind of thing this way in the operation description.
The CLI can't take an operation description listing legal values like
bar[*].baz and use it the same way it can use plain old "bar". The
string "bar[*].baz" is not valid input to send to the server; the user
has to replace the * with a number. Since the CLI can't just use the
string as is, there's not much benefit sending a bunch of text from the
server.
Fundamentally, the CLI needs to specially handle the parameter names for
the "write-attributes" op, and the value for the "name" parameter for
the "write-attribute" op:
1) There needs to be special tab completion behavior. For example, after
the user types 'bar', if they hit tab, in the write-attributes case, the
output is
. =
This reflects that the user can either provide a deeper path into the
complex attribute, or move on to specifying the value of param "bar".
In the write-attribute case, after the user types name=bar and hits tab,
the output is:
. ,
Comma instead of = to indicate they want to move on to the next param.
Similar stuff for the [ and ] chars when dealing with lists.
2) Before sending a low-level op, the CLI validates the op's param names
against the param names listed in the operation description. This
validation should understand how to validate bar[0].baz.
These two aspects of behavior could just be hard-coded into the CLI. To
be formal though, we could add a couple pieces of boolean metadata to
the parameter description:
a) one indicating that the parameter name itself can be expanded into a
deeper path. This would be used in the params to the "write-attributes" op.
b) one indicating that the parameter value can be expanded from the
formally specified legal values. This would be used with the "name"
param for the "write-attribute" op, if we ever improved its description
to properly list the legal values.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9:14 a.m.
New subject: A write-attributes op, and dealing with complex attribute paths
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 have similar problems with proposal b). What’s the intention behind the nested attribute
syntax? A more convenient way to address complex attributes? Or does this address
attributes that belong to child resources?
4:08 p.m.
New subject: A write-attributes op, and dealing with complex attribute paths
On 12/12/14, 2:14 AM, Heiko Braun wrote:
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
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.
9:24 a.m.
New subject: A write-attributes op, and dealing with complex attribute paths
Thanks for the clarification Brian.
On 12 Dec 2014, at 16:08, Brian Stansberry
<brian.stansberry(a)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
8:42 p.m.
I would like to raise once again the issue of nested attribute groups.
I started rewriting iiop subsystem so that it uses attribute groups and I think that in
many cases it would be covenient and more descriptive if we are able to nest attribute
groups.
There are two models related to it: subsystem xml description and management api but I
believe that both of them may benefit from nested attributes.
Example:
Currently ior-settings xml tag is used to group all ior releted configuration:
<ior-settings>
username_password" (...)/>
config caller-propagation="supported" (...)/>
ior-settings>
After attribute group refactor it would currently turn to:
username_password" (...)/>
config caller-propagation="supported" (...)/>
It would be nice to be able to group them together once again. This may be achieved by
adding methods to PersistentResourceXMLDescription which will make it possible to create
more complex xml schema independent of attribute groups. On the other hand, what is
beneficial from xml point of view may also be beneficial for management tools: if those
three elements have all different groups there they will be displayed separately after
sort but if we created a nested groups and do a nested sorting of them then they could be
grouped together in management tools too. Moreover, all information about attribute will
still be containted in its definition and subsystem creation using
PersistentResourceXMLDescription will stay as simple as it is now.
Having that in mind I would suggest extending the group notion from flat to nested and
create direct mapping between group parts and xml tags.
In the above example we would have:
AttributeDefinition INTEGRITY =
(...).setAttributeGroup("ior-settings.as-context")(...)
AttributeDefinition AUTH_METHOD =
(...).setAttributeGroup("ior-settings.sas-context")(...)
AttributeDefinition CALLER_PROPAGATION =
(...).setAttributeGroup("ior-settings.transport-config")(...)
PersistentResourceXMLDescription xmlDescription =
builder(IIOPResourceDefinition.INSTANCE).addAttributes(IIOPResourceDefinition.INTEGRITY,IIOPResourceDefinition.AUTH_METHOD,IIOPResourceDefinition.CALLER_PROPAGATION)(...)
This would create parser able of parsing:
xmlns="urn:jboss:domain:iiop-openjdk:1.0">
(...)
<ior-settings>
username_password" (...)/>
config caller-propagation="supported" (...)/>
ior-settings>
(...)
Problems:
How to represent the group in management api?
LIST vs STRING
:read-attribute-group(group=foo.bar) vs :read-attribute-group(group=[foo,bar])
:read-attribute-group(group=foo) vs :read-attribute-group(group=[foo])
String seem more convenient but there are some consequences of keeping a LIST (which
attribute group actually is) in the form of the STRING: some parts of management client
code will have to do additional work because of that
(f.e. string parsing), tab completion feature will have to hint string part by part which
may be not consistent with other parts of api etc.
----- Original Message -----
From: "Brian Stansberry" <brian.stansberry(a)redhat.com>
To: wildfly-dev(a)lists.jboss.org
Sent: Tuesday, December 9, 2014 9:00:21 PM
Subject: [wildfly-dev] Management model attribute groups
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.
5) Why would I use an attribute group instead of a child resource?
Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.
6) Why would I use an attribute group instead a complex attribute?
Because the various attributes should be independently configurable. In
particular, wiping out the config for all of them by simply undefining
the complex attribute isn't appropriate.
PART II Proposed Work
1) The basics
We add a piece of metadata to the read-resource-description output for
an attribute. Name is 'attribute-group', value type is ModelType.STRING,
value is the name of the group, with 'undefined' allowed.
The group is simply the set of attributes that share the same string.
To implement this, we add public String
AttributeDefinition.getAttributeGroup() and add support for setting it
to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
2) XML parsing/marshalling
Modify PersistentResourceXMLDescription such that attributes in an
attribute group get persisted in their own child element, whose name is
the name of the group.
PersistentResourceXMLBuilder exposes a setter to allow users to turn
this on/off for that resource. Turning it off will allow the addition of
attribute group settings for a resource without requiring an immediate
corresponding xsd change.
3) Web console
HAL can make use of the additional metadata at its leisure, and as it
becomes available.
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.
5) CLI
I'm not clear on exactly what to do here, but my instinct is the output
of the 'ls -l' command should be modified. Probably add a GROUP column
to the right and sort the order of attributes by group and then by
attribute name.
PART III Other possible things to do
A :read-attribute-group(name=<groupname>) operation or an
"attribute-groups=[<groupname>*]" param to :read-resource, to make it
convenient to read a set of attributes without needing to read the
entire resource.
We could also consider adding an "attribute-groups" section to the
read-resource-description output, where a fuller i18n text description
of the meaning of the group could be written. If we do this we should
probably do it in WF 9 as it will likely add some sort of requirement to
subsystem authors that we expose right from the start.
If you're still awake, comments as always are appreciated.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
[1] For example, the JDKORB pull request at
https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
number of places where it seems like attribute groups are a better fit.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3369
days inactive
3426
days old
36 comments
9 participants
participants (9)
-
Brian Stansberry -
David M. Lloyd -
Dev Ops -
Emmanuel Hugonnet -
Heiko Braun -
Jason Greene -
Kabir Khan -
Tomasz Adamski -
Tomaž Cerar