avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: [PROPOSAL] Avalon Components
Date Sun, 12 Jan 2003 14:42:29 GMT
> I'll work to reposition Avalon as
>   - Avalon Framework
>   - Avalon Container
>   - Avalon Components
> AF and AC will be in a single repository, with same committers with same
> access and voting rights. Core Avalon that is. Avalon Components with also
> other committers and voters that use Avalon.

Ok, this is where I see issues ... you see the architecture as layered, I
don't.  I think that the Avalon Container will, especially as it scales, be
built by using Avalon Components.  I do not think that it will be a three
tier layer cake.  Yes, there may be non-core Components, but also core
Components.  And if you decide that core Components would be moved into the
Container module, well I would expect a ThreadPool implementation to be part
of the core, and that is one of the components I'm trying to see fixed.

The bottom line gets down to a bit of fish or cut bait: either make
Committers out of related project developers, or not.  The exception could
be AF, but that is one where even you don't want to be making changes
without very serious consideration, since those are core contracts.

And you have to decide what are the kinds of components you want or not.  I
am very surprised that Peter is now saying that the entire store package
should be pulled from Avalon and moved into James (or other client
programs).  What is the vision?  Perhaps we need to take over the package,
if the Avalon vision doesn't include a storage abstraction.  On the other
hand, I do view data stores as generically useful things, so perhaps we
should be developing a better store for James that *is* part of the Avalon

	--- Noel

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

View raw message