> This sort-of conflicts with the desire to be able
> to guarantee continuity of any ASF release by
> having a sizeable developer pool.
There is a real question, which has been raised more than once, as to how
many containers the Avalon community can and should support. It may
certainly be the case that the Community really can't support to full-scale,
mature containers.
I will make the assertion that there are valid reasons for the existence of
each container currently deployed. If this statement is valid, then the
choices seem to be:
- The Community decides not to support the container,
despite the fact that it fills needs that other
containers don't, and require it to be developed
elsewhere. Not my choice of solution.
- The Community finishes up the great work currently
happening to push out a coordinated release, and
starts work on a next generation container.
The idea of building containers from a container micro-kernel and container
services has been discussed, and seems to resonate well. AIUI, Stephen
represents that Merlin has focused on container internal APIs. Others have
commented that Phoenix was supposed to follow a microkernel model. It seems
to me that there should be sufficient groundwork laid to start a next
generation kernel learning from both Phoenix and Merlin. It should take
what it can from existing containers.
I'm not saying that there won't be significant debate on some choices, but
that is not a bad thing. The internals ought to allow experimentation with
new ways of doing things.
Where there are differing views on implementation, the basic strategy should
be to look at the abstract notion of what the service is supposed to do
within the constuct of the container, and allow different implementations.
The IoC/SoC approach taken by Avalon really helps to promote that option.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
