At 08:55 6/04/01 +0200, Leo Simons wrote:
>> Because Avalon used to be much bigger (It incorporated both
>> Cornerstone
>> and Phoenix)
>
>Actually, since people perceive Avalon as containing all of this:
Same here ;) I have been gradually been separating things out in this
manner aswell ;)
>- server framework specification
Currently that is
org.apache.avalon.Config*
org.apache.avalon.Comp*
org.apache.avalon.Contex*
org.apache.phoenix.* (Kernel related specification)
>- default framework implementation
org.apache.avalon.DefaulyContex*
org.apache.avalon.DefaulyConfig*
org.apache.avalon.DefaulyComp*
>- reusable components
Kernel level components: org.apache.cornerstone.*/*
Non-Kernel components: org.apache.avalon.util.*/*
>- engine for running framework components
org.apache.phoenix.engine.*
org.apache.phoenix.metainfo.*
>I'd argue that Avalon indeed _is_ all of those. What we could
>do is remove all but the framework from Avalon and put it in
>separate projects (reusable components go to commons, phoenix
>becomes a separate project which also provides a default
>implementation),
Unable to be done as Commons wont accept the Avalon "infected" components.
>this would probably be disastrous to Avalon.
>It would require a new web page, new mailing lists etc to
>provide a separation which isn't there.
I like to think of them as sub-projects of avalon which hopefully wont
affect the brand - what do you think?
>The most logical and clean option while maintaining the strength
>of the Avalon brand, IMHO, would be:
>
>Avalon, Apache Server Framework
>===============================
>- org.apache.avalon - framework specification
> = currently proposed org.apache.framework
> += revised and extended org.apache.framework.atlantis,
> specifying the behaviour of a Kernel, Embeddor,
> and JMX Manager (see /proposal in phoenix cvs
> for descriptions).
Not stable enough yet
> += org.apache.avalon.testsuite against which
> framework implementations are verified. Those
> that pass all tests get to be called "100% Avalon
> Compliant".
good idea
>- org.apache.phoenix - RI of framework aimed at server apps.
> = org.apache.phoenix.* as reference implementation
> of org.apache.avalon, thus the classes currently
> in the proposed org.apache.avalon.
Currently org.apache.phoenix.* is the "specification" along with avalon and
org.apache.phoenix.engine/metainfo is the RI ;)
> += org.apache.phoenix.atlantis becomes an implementation
> and extension of the Kernel, Embeddor and JMX Manager
> interfaces.
Perhaps org.apache.phoenix.engine.atlantis.* ???
> += org.apache.avalon.demos, the current demos from
> cornerstone.
-1 What do demos have to do with kernel? - especially as they are meant to
be demoing the reusable components in the next section.
>Notes:
>------
>- I feel the framework should also define how components/blocks
>are handled, and thus define what our current phoenix should
>look like.
Not sure what you mean here - I though it did ? ;)
>- Moving the implementation of the specification to phoenix will
>strengthen phoenix's branding (tomcat is the RI of specs
>defined by javasoft, phoenix is the RI of specs defined by
>apache Avalon).
will do that in the future but it is not yet stable enough to do this IMHO ;)
>- By extending/cleaning up atlantis, it will become easier for
>others to create an AvalonKernel (i.e. phoenix). Phoenix would
>also be easier to program to, as its interfaces are now set in
>stone. This will allow for example Cocoon to create a
>CocoonKernel which implements AvalonKernel by wrapping around
>PhoenixKernel.
+10000
>- I feel a RI also needs a few demos to show how a framework
>could be used. This is, again, in line with the model followed
>by javasoft (the JMX RI provide some sample MBeans, for example).
Agreed. Volunteering? ;)
>Summary:
>--------
> I think it is the best move in both a logical and a
> marketing sense, to make Avalon a specification of a
> framework, and Phoenix the reference implementation
> of that framework.
Depends on what you mean. In 90% of the places I use the Avalon "framework"
it does not have anything to do with a kernel and thus I don't see how
making phoenix the RI is useful.
> - likewise, it will be easier to develop a new
> implementation as parts of phoenix are easily re-used.
Agreed - we have to get one version working 95% before we start cleaning it
up IMHO ;)
>This might take a lot of time, and is certainly not all neccessary
>for version 4 of the framework. Until phoenix is updated as well
>to become the reference implementation of the framework, a temporary
>location for the 'draft' reference implementation could be just about
>anything, like
Sounds like a long term goal ;)
>Proposals:
>----------
>- Avalon remains the main brand for all things related to it,
> while Phoenix is for now a sub-brand of Avalon providing a
> reference implementation of Avalon.
+1
>Finally:
>--------
>I realise that what I've lined out here is a big move from the
>current setup. I decided to look at the issue of organisation
>with a clear mind, forgetting what I knew of the current setup.
>This led to this proposal. Please try to look at it purely from
>a design POV first, without bothering with the things that might
>be broken. Hopefully, you'll agree with me this is indeed the
>smartest thing to do.
I think that except for merging notion of kernel and non-kernel stuff I
agree except as indicated above ;) I am just taking a slower approach but
have been pushing for many of these things since joining up to Avalon ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
