Avalon Spec [Was: A Foolish Consistency]

[hammett <ha...@uol.com.br>]

----- Original Message ----- 
From: "Niclas Hedhman" <ni...@hedhman.org>

> Everyone in the 'lightweight camp' seems to make a

I strongly suggest you to stop using these kind of terms.

>     "Strict Contract" == "Huge Contract"
>
> And I think that is where the main mindset block is sitting.

I would never had other opinion. Quoting you "It is all about Component
Interoperability, at container-level, at IDE level, at search tools level,
and every other conceivable application that may be  interested in looking
at the component."

Did you miss the kitchen sink?

My opinion: small steps.


> So we have a 'conflict'. If we do (7), then it is a Avalon Framework

We are under Avalon. I don't see any problem in obligate to use interfaces
to express requirements. OTOH I think we should evolve to support
constructor injection and setter injection, but thats another discussion.

> Then declare your typical AF4 component
>
>     MyComponent requires GenericStartableSpecification
>     MyComponent compliesWith AvalonStartableSpecification

I'm not sure about your suggestion. I - personally - don't like to relies on
developers to do the right thing. We can find out what a component expects
by inspecting it (search for metadata, interfaces implements, constructors
declared and so on)


> 1. Specifications should be small.

+1

> 3. That Avalon today already contain a lot of these specs, but lumped
together
> under the AF4 umbrella, making it an 'all-or-nothing' (just like EJB)
spec.

Why all or nothing?

> What do you ALL think?

I think you're in the right path. But I'd like to see everyone's opinions
about it.


cheers!
hammett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

RE: Avalon Spec [Was: A Foolish Consistency]

[Andreas Oberhack <de...@softwarefabrik.biz>]

Hi Niclas,

great post!! I really got the full power of your thoughts about RFD,
specs, TCK etc.! That's THE big step ahead.

Do you already have something like a roadmap? I'm really looking forward
to work on the tooling side of the specs!

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Avalon Spec [Was: A Foolish Consistency]

[Niclas Hedhman <ni...@hedhman.org>]

On Tuesday 13 April 2004 20:27, hammett wrote:

>> 3. That Avalon today already contain a lot of these specs, but 
>> lumped together under the AF4 umbrella, making it 
>> an 'all-or-nothing' (just like EJB) spec.

> Why all or nothing?

Correction; All-or-nothing albeit small....

Well, I see it like this; Either a component is AF4 or it is not. A non-AF4 
container, which doesn't know the details of the AF4 specification, must 
assume that the component can not be run in its environment, provided it 
could figure out it is an AF4 component in the first place...
For a container that doesn't give a damn, it would instantiate it, and get 
'mixed results', for instance maybe such container would understand that 
there were start() method, and call it, and a 'weak component' would start in 
some inconsistent state, whereas a 'stronger component' would throw some for 
of IllegalStateException (other lifecycle methods has not been called).

But I think all of this is beside the point. 
My point is; Small Specifications that can be stacked together and form larger 
entities. Light-weight containers can implement an arbitrary set of 
specifications, and components likewise "require", "request" and "complyWith" 
any arbitrary set. Then do a simple matrix;

Spec              | Fortress | Merlin | Nano | Dojo | ContainerX |
------------------+----------+--------+------+------+------------+
ConstrInjection   |    -     |    c   |   c  |  c   |     c      |
SM-Injection      |    c     |    c   |   -  |  c   |     -      |
GenericStartable  |    c     |    c   |   -  |  c   |     c      |
AF4Startable      |    r     |    r   |   -  |  r   |     -      |

c=compliesWith
r=requires
-=not supported

And for each component developed, we do the same thing. And since these are 
machine-readable (my goal with all of this) those tables can be automatically 
generated, as well as a tool can figure out which components will work with 
which containers.

It can change the world, but perhaps Avalon is the wrong forum for 
'Specification' talks...


Finally; Hammet, I would like to urge you to be more positive in the future 
(last response was an improvement!) and not only come with negative criticism 
at all times. You spoke highly of 'we must learn more about community and 
respect', which I applaud, but you are one of us who have to learn as well 
:o). Don't focus on 'disagree', focus on 'agree' and 'agree, how about...' 
aspects of the debate. I am trying to do so now, and you won't hear anymore 
"negativism" from me.
I have the impression that you seek to maintain the current AF4 Status Quo, 
but OTOH you never say it outright either, so I am somewhat confused over 
what your true agenda is... Perhaps your positive views could be posted?


Cheers
Niclas
-- 
+---------//-------------------+
|   http://www.bali.ac         |
|  http://niclas.hedhman.org   |
+------//----------------------+

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org