> On Oct. 30, 2015, 12:02 p.m., Justin Ross wrote: > > I don't understand the true constraints here. It seems to be a UI-driven > > one, about what should be listed in the UI and what should not be, so I'd > > search more in the direction of indexed=false or listed=false or > > hidden=true. > > > > In any case, I think "referential" is the wrong word. It's (1) obscure and > > (2) doesn't unambiguously indicate the referent in this usage. I guess > > referent=true would, but again, too weird. If you go with some variant of > > refer, I'd go referenceable. A third grader would understand that.
Background: we have managed "entities" which are things with attributes, such as connections or connectors. Some of those entities (in particular connections/connectors) have fairly complicated "groups" of related attributes that often have the same settings for multiple entities, for examle the same SSL settings for many connections. We call those groups "annotations" after the AMQP management spec (another poorly chosen word) and in a config file you can specify the group of attributes once and name it, then refer to it by name in several entities as a shorthand compared to repeating all the attribute values. The original UI just shows each entity with all its attributes flattened out, but it is easier to read e.g. the SSL attributes by turning them into a named group because the attribute values themselves are long and usually not that interesting, it is more interesting to quickly identify which connections have the *same* set of attributes. However not all things that are "annot ations" in the schema are interesting in this way, hence the search for a way to identify the ones that are. Its very possible that some rework of the schema could help too, to align the use of annotations more closely with "things that are interesting to name as groups" so they could be one and the same. Annotations evolved by munghing ideas in the original dispatch config file with related ideas in the AMQP management spec, they may not have reached their ideal form yet. - Alan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39596/#review104553 ----------------------------------------------------------- On Oct. 27, 2015, 4:31 p.m., Ernie Allen wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/39596/ > ----------------------------------------------------------- > > (Updated Oct. 27, 2015, 4:31 p.m.) > > > Review request for qpid, Alan Conway, Ganesh M, Kenneth Giusti, mick goulish, > and Ted Ross. > > > Repository: qpid-dispatch > > > Description > ------- > > Adds a new attribute to entities named referential. If true then the > entity/annotation could be referred to by name. This is to give the console > enough information to separate out the sslProfile attributes. > > schema.py can already handle the case where a listener/connector contains a > ssl-profile=<sslProfileName> attribute. > > I chose the name 'referential' to indicate that an annotation can be referred > to by name. Another possibility is 'referable'. > > I also added an "references" list to an entity in the JSON schema. This list > is only emitted if any of the entity's annotations are marked as referential. > > > Diffs > ----- > > python/qpid_dispatch/management/qdrouter.json c5b1edb > python/qpid_dispatch_internal/management/schema.py 8f7e961 > > Diff: https://reviews.apache.org/r/39596/diff/ > > > Testing > ------- > > bin/test.sh > > > Thanks, > > Ernie Allen > >
