[jboss-as7-dev] Automagic Interfaces

[Jason T. Greene]

On 7/25/11 6:50 AM, Heiko Braun wrote:
>
>
> Not sure if we are on the page wrt to this discussion.
> (you lost me somewhere) but here are my thoughts about the value type
> descriptions
> and automagic interfaces:
>
> Instead of using the VALUE_TYPE descriptions to get to know the inner
> structure of a complex attribute,
> we could aim for a more simple approach: turn complex attributes into
> sub resources.

It's a good argument (although I don't completely agree) for the 
configuration model. However we still need complex structures (and a way 
to describe them) for runtime operations. So my argument is that all of 
our tools need to be able to understand ad-hoc request/responses anyway.

>
> This is not possible straight away and has certain implications:
>
> *Sub resources need to be addressable*
>
> Consider the "jsp-configuration" of subsystem web for instance.
> it's not addressable per se, but it easily can be made addressable:
>
> /subsystem=web/config=jsp:read-resource
> /subsystem=web/config=jsp:read-attribute(name=development)
>
> What do we gain? implicit operations for a the sub resource:
> (add, remove, read/write-arribute, etc)

In this particular example I agree, however there are still some issues

1) Breaking compatibility
2) Address-ability is not so useful for runtime and read-only values
3) Singletons lead to making up k-v pairs
4) Some things (admittedly not extremely common) can only be modified in 
an atomic group of values.
>
> With this we are much closer to automagic interfaces,
> then the burden parse & analyze some half-baked description of the
> structures at hand.
>
> Why "half-baked"? Well, IMO the current description of types and
> constraints are straight forward
> and easy to understand, but far from be descriptive enough to
> automagically generate interfaces.

Well we should figure out what the gaps are. It could be that some are 
incomplete.
>
> It's still very hard to generate human interfaces from proper xml schema
> descriptions
> and the DMR descriptions don't cover the detail and descriptiveness of
> xml schema yet.
> And in my opinion the shouldn't.

Well a ironically good chunk of schema is a vast array of features to 
human maintenance and control of the document. The descriptions we have 
been creating are intended to be read by machines, so redundancy for 
example is less of a concern.

We also want to use them for request validation at some point to make 
operation implementations less work and more consistent and catch more 
errors.

As mentioned above this is already a must have for runtime ops, and we 
already went through a lot of trouble to provide them for the model. I 
mean the whole rationale was to support dynamic interfaces. It would be 
a shame if we fall short.

>
> We better stick to our simple & straight forward mantra
> and improve/refactor the current model descriptions like described above
> before puling the sledgehammer.

Hmm wouldn't it be more destructive to drastically change everything and 
break compatibility. I mean I agree we should do it in a few areas, but 
if the goal is not use a sledgehammer then we should just leave the warts.

> Ike
>
> On Jul 25, 2011, at 1:21 PM, Jason Greene wrote:
>
>> Not every complex structure in the DMR tres is addressable. You can
>> have a single attribute that contains multiple values (like passing a
>> map Iin Java, a struct in C etc).
>>
>> Read-description is supposed to describe the structure of these
>> complex attributes using VALUE_TYPE
>>
>> Sent from my iPad
>>
>> On Jul 25, 2011, at 5:09 AM, Heiko Braun <hbraun at redhat.com
>> <mailto:hbraun at redhat.com>> wrote:
>>
>>>
>>>
>>> Can you elaborate on this?
>>> I don't understand what you mean ...
>>>
>>> On Jul 23, 2011, at 2:26 PM, Jason Greene wrote:
>>>
>>>> If we allow value types then all of our interfaces need to know how
>>>> to handle them
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Jason T. Greene
JBoss, a division of Red Hat