[jboss-as7-dev] Detyped API document feedback

[Brian Stansberry]

On 1/4/11 4:39 PM, David M. Lloyd wrote:
> On 01/04/2011 04:15 PM, Brian Stansberry wrote:
>
>>> 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.
>

At least for 7.0. Adding an exclusion algorithm and loosening the rules 
is something that can be done later if need be.

>>> 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".
>

You mean a value type whose ModelType is VALUE_TYPE? I'm confused what 
that would mean. But no worries; this is details.

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat