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