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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
