avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: back to branding
Date Sun, 08 Apr 2001 00:31:32 GMT
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message