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
>>> On 12/10/14, 11:44 AM, David M. Lloyd wrote:
>>>> I.e. I should be able to do something like
>>>> 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
> 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
> the resource's "add" operation.
Why is that a problem? It's essentially the same thing in most cases,
> 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.
Senior Principal Software Engineer
JBoss by Red Hat