avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [POLL] Where does people stand?
Date Fri, 05 Mar 2004 13:10:15 GMT
Of course, as many have noticed, this is a very low-precision
way of explaining your position, but I hope it will average 
out in the end...

A more verbose answer follows below my quick answers.

> From: Niclas Hedhman [mailto:niclas@hedhman.org] 
>
> Components are more than code.
> [X] Correct
> [ ] Incorrect
> 
> 
> Components should come in "a box", dropped in place and used 
> without even need 
> to look at it.
> [X] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component User more important than simplicity 
> for Container 
> Developer.
> [X] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component Author more important than 
> simplicity for Container 
> Developer.
> [X] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component User more important than simplicity 
> for Component 
> Author.
> [X] Correct
> [ ] Incorrect
> 
> 
> Without a large Component Repository, COP is pretty 
> meaningless. [ ] Correct [X] Incorrect
> 
> 
> COP is not the same as Java classes defined over an API. I.e. 
> just because you 
> can instantiate it, doesn't mean it is a Component.
> [ ] Correct
> [X] Incorrect
> 
> 
> Avalon is about a domain-neutral server framework.[1][2]
> [X] Correct
> [ ] Incorrect
> 
> 
> Components should be runtime replacable. A true server 
> doesn't need restart. [X] Correct [ ] Incorrect
> 
> 
> Avalon-compliant Components could be made to work in 
> non-Avalon-compliant 
> containers, effectively running as POJOs, by the Component 
> Author. [X] Correct [ ] Incorrect


VERBOSE SECTION
---------------

> Components are more than code.
> [X] Correct
> [ ] Incorrect

Can be more than code, but they don't *have* to be.
 
> Components should come in "a box", dropped in place and used 
> without even need to look at it.
> [X] Correct
> [ ] Incorrect

Ideally, yes. But we should not limit the box design by *requiring*
a certain component packaging.

You make me think of .sar or .war files, which are not always the
right way to deploy things.

However, if you *want* to deploy your components like .war or .sar
files, the framework should not make it impossible.

> Simplicity for Component User more important than simplicity 
> for Container Developer.
> [X] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component Author more important than 
> simplicity for Container Developer.
> [X] Correct
> [ ] Incorrect
> 
> 
> Simplicity for Component User more important than simplicity 
> for Component Author.
> [X] Correct
> [ ] Incorrect

No further comment needed. The above is obvious.
 
> Without a large Component Repository, COP is pretty 
> meaningless. [ ] Correct [X] Incorrect

COP gives you an architectural framework that is very
useful even if you have to write all your components yourself.

> COP is not the same as Java classes defined over an API. I.e. 
> just because you 
> can instantiate it, doesn't mean it is a Component.
> [ ] Correct
> [X] Incorrect

That depends on the component framework. For Avalon, the answer
is "Correct" but for COP the answer is "Incorrect".

> Avalon is about a domain-neutral server framework.[1][2]
> [X] Correct
> [ ] Incorrect
> 
> 
> Components should be runtime replacable. A true server 
> doesn't need restart. [X] Correct [ ] Incorrect

Ideally yes.

A component framework should not by design make runtime-replacement
an impossibility. But it should not require that components are
coded for it.
 
> Avalon-compliant Components could be made to work in 
> non-Avalon-compliant 
> containers, effectively running as POJOs, by the Component 
> Author. [X] Correct [ ] Incorrect

In effect, an Avalon component running in a container is a POJO.

/LS


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


Mime
View raw message