[jboss-as7-dev] Detyped API document feedback

[David M. Lloyd]

On 01/04/2011 04:15 PM, Brian Stansberry wrote:
>> The registry of operations should be external to the model itself; it
>> would be a map with a key that corresponds to the operation name plus a
>> "path" specification to the applicable node type.
>
> Yes, that's the way it's meant to work.
>
> There are 2 key differences in what I see you describing vs the client
> side view of a ManagedResource described on the wiki article:
>
> 1) A ModelNode sent from the server to the client (e.g. via your "read"
> operation below) would not include any complex metainformation -- no
> equivalent to MBeanAttributeInfo, MBeanOperationInfo, etc. Instead, a
> user interested in that kind of metainformation would execute a
> different operation to get it.
>
> I think that's good.
>
> 2) There's no distinction between an "attribute" and another entity
> that's in a parent-child relationship. What that means in practical
> terms is the "read" operation you describe executed with address
> "base=domain" would pull down the whole model, with no simple way to
> just pull down the attributes of the parent and not the
> separately-addressable children.
>
> Thinking about it though, that's probably ok. People are almost always
> going to want to read a single attribute or a whole subtree.

Yeah that was my thinking.  If it turns out not to be the case, then we 
could possibly add a "prune" flag to the read operation or something, or 
revisit it in some other way.

>> Some operations (like
>> "read") would be generic and would apply to any node path, where some
>> (like the example above) would be highly specific.
>>
>
> We'll have to have rules for this such that there is no ambiguity about
> what operation is meant (i.e. there can't be a "read" operation
> associated with some subsystem address.) I think that means a limited
> set of operations like "read" that are global to all addresses and whose
> names are reserved. Everything else is like your example above.

Maybe.  It might be handy to be able to override operations; or it might 
just cause trouble.  If the former, we can use a "most-specific-match" 
algorithm for operations.  If the latter, we can use some mutual 
exclusion algorithm where operations *may* have the same names but not 
if they overlap in any way.  That way we can have a uniform rule without 
having to reserve names (which can be tricky later on if you want to add 
more names to your "reserved" list).

Now that you mention it, I think maybe you're right, and we should 
prevent overlapping operations.

>> Of course this bypasses the other half of the problem which is
>> describing the model and available the operations.  But, by having a
>> special value type for representing a value type,
>
> Do you mean "a special value for representing a value type"? What you
> describe below looks like an ordinary value with a well-known structure.

I just mean that there is a value type whose ValueType is VALUE_TYPE.  I 
guess you could say "a special value called VALUE_TYPE for representing 
a value type of ValueType".

-- 
- DML