> G'day Pete:
>
> > The problem is associated with our branding - what do we
> > want to be branded as? Because Avalon used to be much bigger
> > (It incorporated both Cornerstone and Phoenix) many people
> > associate it with Phoenix. Others associate it
> > plainy with framework part ... others the components etc.
>
> Today the Avalon "brand" covers three things (and don't hesitate
> to correct or suggest other views), and its in the definition of
> these three things that I think the "branding" question get
> confusing:
>
> 1 "Avalon - the framework stuff"
> 2. "Phoenix - the engine stuff"
> 3 "Cornerstone - the blocks stuff"
>
> Today Avalon (the brand) represents 1, 2 and 3. In Pete's message
> he's talking about Avalon in terms of point 1, not in terms of 1..3.
> I think that maybe we do have a "brand management" problem (wow,
> actually got in the 'm' word on an open-source list :-)). There
> are two exit mechanisms here:
I've got another one that models the current setup in many java
specifications:
> Because Avalon used to be much bigger (It incorporated both
> Cornerstone
> and Phoenix)
Actually, since people perceive Avalon as containing all of this:
- server framework specification
- default framework implementation
- reusable components
- engine for running framework components
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), 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.
It could be there, but it isn't and it is also unlikely to
get here soon.
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).
+= org.apache.avalon.testsuite against which
framework implementations are verified. Those
that pass all tests get to be called "100% Avalon
Compliant".
- 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.
+= org.apache.phoenix.atlantis becomes an implementation
and extension of the Kernel, Embeddor and JMX Manager
interfaces.
+= org.apache.avalon.demos, the current demos from
cornerstone.
- org.apache.components - library of reusable components
= current org.apache.cornerstone minus demos and not
very reusable code.
- org.apache.log - nothing new here ;)
Notes:
------
- I feel the framework should also define how components/blocks
are handled, and thus define what our current phoenix should
look like.
- 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).
- 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.
- 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).
- components is a more clear name than cornerstone, IMHO. Doesn't
matter much though.
- if we wish to define logging of Components in the framework
specifications, then there should indeed be org.apache.avalon.log.
This means phoenix would have org.apache.phoenix.log, which
makes use of LogKit.
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.
This will clarify to the world what Avalon is, and also
strengthen the Phoenix brand. It follows the setup used
for official java specifications, which has many
advantages:
- it will become easier (even transparent) for users
of Avalon-enabled components to swap implementations
- likewise, it will be easier to develop a new
implementation as parts of phoenix are easily re-used.
- the separation between interface and implementation
is complete.
- the model will be similar for anyone who has worked
with existing java specifications, thus reducing the
learning curve.
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
org.apache.avalon.implementation
org.apache.framework
org.apache.phoenix.implementation
etc etc. Of these, I prefer the first, but Pete likes the second
more because of greater separation between the two, which is also
fine with me.
This leaves the unstable/nonfinished part of the specification.
I suggest using
org.apache.avalon.draft /
org.apache.avalon.dev /
org.apache.avalondev
for that.
Proposals:
----------
- a long-term movement to the structure I've explained above,
for reasons mentioned above.
- if it is not feasible to modify phoenix to be the reference
implementation of the framework in time (i.e. May), put the
reference implementation in org.apache.framework until it is.
- 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.
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.
regards,
Leo Simons
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("[EMAIL PROTECTED]");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
