You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/06/15 15:46:19 UTC
[POA] How to work towards A5
In order to focus our energies on A5 without spinning our wheels on
certain
things, I suggest we take a look at the A5 proposal directory in CVS.
For
those who don't know it is in ${jakarta-avalon}/src/proposal/avalon5/.
I propose that we go through, package by package to determine if there
are
any changes that need to be made. With that said, I also propose that
we
save the component package for last as that is the one with the most
controversy.
Here are the design constraints we should work with:
* Make things easier for the user of the framework--not harder
* Provide a compelling reason to move forward
* Provide a compatibility layer so that the progress of moving from
A4 to A5 is seemless (i.e. package naming changes).
* Solidify the contracts between the container and the component
As of right now, there are things that surround A4 design that we need
to
look at. Some of them have been thorns in our side for some time now,
but
this provides the mental framework of what we are trying to solve.
* Mixing of certain concerns
- The component lookup mechanism (ComponentManager/ComponentSelector)
mixes the concern of lookup and explicit release. No other known
lookup mechanism requires you to release resources back to it.
+ We need to determine if these concerns need to be mixed for
practical
reasons.
+ If not, we need to determine how to address pooled components
without
an explicit release satisfactorily
- The definition of role/subrole was handled by two different
entities,
and we need to merge that into one.
+ Noone was truly happy with the ComponentSelector (something that
attempted a unified way of selecting subroles within a major
role).
+ The plumbing of default role and remapping of sub roles was
removed
from the container--which is a container concern
* Container contracts insufficiently defined
- There are several different containers in Excalibur and Phoenix.
All
of them have different meta-models and different rules for defining
the
component's lifestyle and role mapping.
+ The existence of different meta-models mean that the containers
are
only _partially_ compatible. The developer is responsible for
rewriting
the meta data to make the component work in each container. Not
optimal.
+ The meta models need to provide enough information for the
container to
make decisions but not so much that it artificially constrains the
container.
- Lifecycle is very well defined, but do we need to add any lifecycle
stages?
+ What about component persistence (working dataset, runtime
configuration
changes).
+ What about a planned way of adding in new application specific
lifecycle
methods?
- Some have identified this as a need, and have either already put
effort
into it or are willing to.
- Such changes render the component that uses the new lifecycle
stages
backwards incompatible--hense the need to extend the container
at the
framework level.
- Are there more?
-----
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [POA] How to work towards A5
Posted by Leo Simons <le...@apache.org>.
On Sat, 2002-06-15 at 15:46, Berin Loritsch wrote:
> In order to focus our energies on A5 without spinning our wheels on
> certain
> things, I suggest we take a look at the A5 proposal directory in CVS.
> For
> those who don't know it is in ${jakarta-avalon}/src/proposal/avalon5/.
>
> I propose that we go through, package by package to determine if there
> are
> any changes that need to be made. With that said, I also propose that
> we
> save the component package for last as that is the one with the most
> controversy.
It seems logical we should make framework-wide decisions before we do
any of that. Are we done there?
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [POA] How to work towards A5
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Shall we make all of these a separate thread to focus on?
> Lie [A5-1] Lookup-Management; [A5-1] Pooling, etc...
Absolutely!
And a separate thread for each package as well!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [POA] How to work towards A5
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> In order to focus our energies on A5 without spinning our wheels on
> certain
> things, I suggest we take a look at the A5 proposal directory in CVS.
> For
> those who don't know it is in ${jakarta-avalon}/src/proposal/avalon5/.
>
> I propose that we go through, package by package to determine if there
> are
> any changes that need to be made. With that said, I also propose that
> we
> save the component package for last as that is the one with the most
> controversy.
Thanks Berin for this thread. Most appreciated :-)
> Here are the design constraints we should work with:
>
> * Make things easier for the user of the framework--not harder
> * Provide a compelling reason to move forward
> * Provide a compatibility layer so that the progress of moving from
> A4 to A5 is seemless (i.e. package naming changes).
> * Solidify the contracts between the container and the component
+10000
> As of right now, there are things that surround A4 design that we need
> to
> look at. Some of them have been thorns in our side for some time now,
> but
> this provides the mental framework of what we are trying to solve.
>
> * Mixing of certain concerns
> - The component lookup mechanism (ComponentManager/ComponentSelector)
> mixes the concern of lookup and explicit release. No other known
> lookup mechanism requires you to release resources back to it.
> + We need to determine if these concerns need to be mixed for
> practical
> reasons.
> + If not, we need to determine how to address pooled components
> without
> an explicit release satisfactorily
> - The definition of role/subrole was handled by two different
> entities,
> and we need to merge that into one.
> + Noone was truly happy with the ComponentSelector (something that
> attempted a unified way of selecting subroles within a major
> role).
> + The plumbing of default role and remapping of sub roles was
> removed
> from the container--which is a container concern
+1
Shall we make all of these a separate thread to focus on?
Lie [A5-1] Lookup-Management; [A5-1] Pooling, etc...
> * Container contracts insufficiently defined
> - There are several different containers in Excalibur and Phoenix.
> All
> of them have different meta-models and different rules for defining
> the
> component's lifestyle and role mapping.
> + The existence of different meta-models mean that the containers
> are
> only _partially_ compatible. The developer is responsible for
> rewriting
> the meta data to make the component work in each container. Not
> optimal.
> + The meta models need to provide enough information for the
> container to
> make decisions but not so much that it artificially constrains the
> container.
+1
> - Lifecycle is very well defined, but do we need to add any lifecycle
> stages?
> + What about component persistence (working dataset, runtime
> configuration
> changes).
> + What about a planned way of adding in new application specific
> lifecycle
> methods?
Very important for my project and for James, which is starting now to
define the new Mailet API. Let's hope Paul and I succede in showing the
community the strenghts of Avalon.
> - Some have identified this as a need, and have either already put
> effort
> into it or are willing to.
> - Such changes render the component that uses the new lifecycle
> stages
> backwards incompatible--hense the need to extend the container
> at the
> framework level.
- Exception handling
+ Runtime vs Exceptions
+ Proper rules for Exception handling
+ System to notify the system of things (move Notifying from Cocoon
to Excalibur)
- Add a GUI-Web interface for management and programming with Avalon.
- Refer to the containers as reference implementations, and give ready
to use containers.
- have fun! :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>