You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2004/03/10 01:36:04 UTC
[RT] Purpose of Avalon
This Random Thought is trying to touch on the Purpose of Avalon, as I believe
that there is a large chasm regarding this subject, and that the view of
active developers may not be the view of our users, current and future.
***** Avalon - The Apache Server Framework *****
Bold statement indeed, but apparently not bold enough, as Avalon has outgrown
this statement, and some say it should now fit inside anything from an credit
card to an airline booking system (exaggeration intended) and preferably
without any differentiation of codebase. It should be tweakable to fit inside
any other technology out there, without any demands placed on that
technology, and ohh..., throw in some GUI applications as well.
This has gone completely out of proportions. Face it, what is the bottom line
purpose of Avalon or ANY other OSS project;
***** To serve our users *****
and not to serve our egos, or the academic research paper on ultimate
scalability that will earn my doctor's degree.
- o - o - So what are our Users' needs?? - o - o -
Well, to answer that question, we need to look at WHO is our users?
Traditionally, we have always turned to Cocoon, Turbine and James, but are
they truly the real users, and are they really the main beneficiary of
Avalon.
If the answer to this is YES, then the future direction of Avalon is very
simple, shut down Merlin and Fortress, and continue to evolve ECM and
Phoenix. As Mr Sutic explains "migrating to Merlin would not translate into a
single $ for me" and conclude that migrating away from ECM for Cocoon doesn't
solve anything per se, only a hope that the next container will come up with
something better for them in the long run.
- o - o - Are our users Cocoon, Turbine and James??? - o - o -
I think NO, they are part of our user base, but they are not even the main
beneficiary of Avalon technology.
- o - o - How can that be? - o - o -
Projects like these three are large, independent and basically don't have any
commercial constraints. There is very little **re-use** involved !!
Face it! The real beneficiaries are all those developers out there, who crank
out 2-5 applications a year, often within the same problem domain, for
different customers. All are slightly different, but the bulk is **re-use**.
The developers who currently use copy-paste to move from project to project,
are the ones who can really get a performance boost out of COP, NOT the large
monolithic product developers.
Stephen mentioned to me something in the region of a 1000 downloads of Merlin
a day. If that is true, it is a shame we don't manage to attract many of them
to stay on (which can be seen on user@ if anyone reads it). I think the
reasons are;
1. "Which container?"
2. Too few components.
3. No documentation of the components that do exist.
4. It is unclear what the benefits for the corporate developer are, when
hitting the official website.
5. We are not "political correct".
- o - o - The Way Forward - o - o -
Avalon and its community have a lot of choice, and need to make decisive
action, or it will become a dead project and laughing stock of the ASF.
* Absorb a Unifying Vision (see separate post later).
* Drop the concentration on container toolkit, support of IoC types, and
similar academic issues. Those interested in these exercises can and already
do this outside this community, which is fine, but let's not get divided over
things that doesn't matter to our emerging users.
* Declare Merlin * The Apache Server Framework *, and create easy access to
the 2-4 common usecases that really exists, not constructed ones to prove
versatility for the academic sake. Transfer ECM to Cocoon. Deprecate
Fortress, or those who are interested bring it elsewhere.
* Focus on component contracts and patterns, which will help the corporate
developer and reusability at large. Flexibility is not performance improving,
and please search the Cocoon mail archive for the word "Flexibility
Syndrome". I want to solve real problems for real people !
* Evolve Merlin to support these new solid contracts.
* Bring MerlinDeveloper to market for rapid prototyping solutions.
* Bring a component publishing infrastructure product into existence, to
simplify the component publishing for non-ASF committers.
- o - o - Conclusion - o - o -
Avalon needs to get a momentum forward, and I will produce the Unifying Vision
in a separate post. Stalemate and in-fighting brings us nowhere.
Avalon has, like Cortez, sailed a long way and there is a jungle of obstacles
in front. Burn the ships!!! Move forward, there is no going back. Those who
want to peddle around with petty things, stay on the beach and pamper ECM,
Phoenix and Fortress. The rest of us, who want to conquer new land, will
forge ahead for fame and fortune (God, King and Country if you prefer :o) ).
Staying on the beach will lead to death in obscurity, without anyone caring
about it.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Purpose of Avalon
Posted by Stephen McConnell <mc...@apache.org>.
Niclas:
I have read this email several times. It's heavy, purposeful, direct and
in my opinion a very good post. If I look for actionable semantics I can
establish the following:
1. put in place a charter (refer Unifying Vision)
2. focus on single Avalon product
3. Transfer ECM to Cocoon
4. Deprecate Fortress
5. Evolve Merlin to support these new solid contracts
6. Bring MerlinDeveloper to market
7. component publishing infrastructure product
With respect to the first point (1). The Avalon charter is as defined by
the Board under the motion taken to establish the PMC. This provisional
charter establishes a scope of "component and service management". I
think the conclusions within the Unifying Vision post provide a good
framework/starting-point for a concrete charter.
The second point (2) is in my opinion *very* important to the subject of
sustainable quality. Since the dawn time other initiative have chosen
to compare themselves with Avalon and to asset Avalon compatibility.
Looking ahead - a single Avalon product, defining the best, delivering
concrete contracts, setting the standard for IoC. This is Avalon. This
is why I joined. This is why I'll stay.
Item three (3) is an option that the Avalon project should present to
the Cocoon project. ECM is after all already deprecated and no longer
part of the Avalon landscape. If Cocoon accepts ECM - case closed.
Otherwise its simply a case of zip it up and place it in the archives.
Item (4) concerns the deprecation of Fortress. I agree. However I think
we should deal with this carefully and in consideration for existing
users. The code base should be moved out of Avalon core CVS and into a
deprecated group. If there is a requirement for ongoing maintenance we
should enable that (or facilitate the migration of Fortress code out of
Avalon as required).
Item (5) means solid focused work on - its non-trivial but we have a
solid foundation to work on and the people to archive it.
Item (6) concerns bring MerlinDeveloper to market and here what is
missing immediately is a work plan the synchronizes the current
MerlinDeveloper platform with the Merlin 3.3. I.e. we need to
synchronize the release of Merlin Developer and 3.3. development ASAP.
Item (7) is not familiar territory for Avalon but it's something close
to my heart. This will change the landscape and Avalon will never look
back. I think we should make sure that the Directory Project are in on
the loop with respect to this subject.
Stephen.
Niclas Hedhman wrote:
> This Random Thought is trying to touch on the Purpose of Avalon, as I believe
> that there is a large chasm regarding this subject, and that the view of
> active developers may not be the view of our users, current and future.
>
> ***** Avalon - The Apache Server Framework *****
>
> Bold statement indeed, but apparently not bold enough, as Avalon has outgrown
> this statement, and some say it should now fit inside anything from an credit
> card to an airline booking system (exaggeration intended) and preferably
> without any differentiation of codebase. It should be tweakable to fit inside
> any other technology out there, without any demands placed on that
> technology, and ohh..., throw in some GUI applications as well.
>
> This has gone completely out of proportions. Face it, what is the bottom line
> purpose of Avalon or ANY other OSS project;
>
> ***** To serve our users *****
>
> and not to serve our egos, or the academic research paper on ultimate
> scalability that will earn my doctor's degree.
>
> - o - o - So what are our Users' needs?? - o - o -
>
> Well, to answer that question, we need to look at WHO is our users?
>
> Traditionally, we have always turned to Cocoon, Turbine and James, but are
> they truly the real users, and are they really the main beneficiary of
> Avalon.
>
> If the answer to this is YES, then the future direction of Avalon is very
> simple, shut down Merlin and Fortress, and continue to evolve ECM and
> Phoenix. As Mr Sutic explains "migrating to Merlin would not translate into a
> single $ for me" and conclude that migrating away from ECM for Cocoon doesn't
> solve anything per se, only a hope that the next container will come up with
> something better for them in the long run.
>
> - o - o - Are our users Cocoon, Turbine and James??? - o - o -
>
> I think NO, they are part of our user base, but they are not even the main
> beneficiary of Avalon technology.
>
> - o - o - How can that be? - o - o -
>
> Projects like these three are large, independent and basically don't have any
> commercial constraints. There is very little **re-use** involved !!
>
> Face it! The real beneficiaries are all those developers out there, who crank
> out 2-5 applications a year, often within the same problem domain, for
> different customers. All are slightly different, but the bulk is **re-use**.
> The developers who currently use copy-paste to move from project to project,
> are the ones who can really get a performance boost out of COP, NOT the large
> monolithic product developers.
>
>
> Stephen mentioned to me something in the region of a 1000 downloads of Merlin
> a day. If that is true, it is a shame we don't manage to attract many of them
> to stay on (which can be seen on user@ if anyone reads it). I think the
> reasons are;
>
> 1. "Which container?"
> 2. Too few components.
> 3. No documentation of the components that do exist.
> 4. It is unclear what the benefits for the corporate developer are, when
> hitting the official website.
> 5. We are not "political correct".
>
>
> - o - o - The Way Forward - o - o -
>
> Avalon and its community have a lot of choice, and need to make decisive
> action, or it will become a dead project and laughing stock of the ASF.
>
> * Absorb a Unifying Vision (see separate post later).
>
> * Drop the concentration on container toolkit, support of IoC types, and
> similar academic issues. Those interested in these exercises can and already
> do this outside this community, which is fine, but let's not get divided over
> things that doesn't matter to our emerging users.
>
> * Declare Merlin * The Apache Server Framework *, and create easy access to
> the 2-4 common usecases that really exists, not constructed ones to prove
> versatility for the academic sake. Transfer ECM to Cocoon. Deprecate
> Fortress, or those who are interested bring it elsewhere.
>
> * Focus on component contracts and patterns, which will help the corporate
> developer and reusability at large. Flexibility is not performance improving,
> and please search the Cocoon mail archive for the word "Flexibility
> Syndrome". I want to solve real problems for real people !
>
> * Evolve Merlin to support these new solid contracts.
>
> * Bring MerlinDeveloper to market for rapid prototyping solutions.
>
> * Bring a component publishing infrastructure product into existence, to
> simplify the component publishing for non-ASF committers.
>
>
> - o - o - Conclusion - o - o -
>
> Avalon needs to get a momentum forward, and I will produce the Unifying Vision
> in a separate post. Stalemate and in-fighting brings us nowhere.
> Avalon has, like Cortez, sailed a long way and there is a jungle of obstacles
> in front. Burn the ships!!! Move forward, there is no going back. Those who
> want to peddle around with petty things, stay on the beach and pamper ECM,
> Phoenix and Fortress. The rest of us, who want to conquer new land, will
> forge ahead for fame and fortune (God, King and Country if you prefer :o) ).
>
> Staying on the beach will lead to death in obscurity, without anyone caring
> about it.
>
>
> Niclas
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Purpose of Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Niclas Hedhman wrote:
>
> On Wednesday 10 March 2004 15:38, Carsten Ziegeler wrote:
> > As I stated, it's up to you guys to define the future of Avalon.
> > Just one question out of personal curiosity: You speak about
> > transfering ECM to Cocoon and dropping Fortress.
> > *If* (just hypothetical) we at Cocoon would decide to continue with
> > Fortress instead of ECM would you consider (also)
> transfering Fortress
> > to Cocoon?
>
> I have no problem at all with something like that.
> Technically, you don't even need permission, just take it :o)
> we are all ASF.
>
:)
> My only concern is "strict contracts & specifications", and
> only to 'entertain' compliant containers. If someone wants to
> keep Fortress here and keep it up to those specs, then _I_
> have no problem with that.
> My target is true "portable component" nothing more and nothing less.
>
Sounds reasonable. Thanks!
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Purpose of Avalon
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 10 March 2004 15:38, Carsten Ziegeler wrote:
> As I stated, it's up to you guys to define the future of Avalon.
> Just one question out of personal curiosity: You speak about
> transfering ECM to Cocoon and dropping Fortress.
> *If* (just hypothetical) we at Cocoon would decide to continue
> with Fortress instead of ECM would you consider (also) transfering
> Fortress to Cocoon?
I have no problem at all with something like that. Technically, you don't even
need permission, just take it :o) we are all ASF.
My only concern is "strict contracts & specifications", and only to
'entertain' compliant containers. If someone wants to keep Fortress here and
keep it up to those specs, then _I_ have no problem with that.
My target is true "portable component" nothing more and nothing less.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Purpose of Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
You really have some good points I totally agree with, especially
the fact, that Cocoon, Turbine and James are not Avalon's only
users and that they are not more important than any other users.
Absolutely right.
As I stated, it's up to you guys to define the future of Avalon.
Just one question out of personal curiosity: You speak about
transfering ECM to Cocoon and dropping Fortress.
*If* (just hypothetical) we at Cocoon would decide to continue
with Fortress instead of ECM would you consider (also) transfering
Fortress to Cocoon?
Carsten
Niclas Hedhman wrote:
>
> This Random Thought is trying to touch on the Purpose of
> Avalon, as I believe that there is a large chasm regarding
> this subject, and that the view of active developers may not
> be the view of our users, current and future.
>
> ***** Avalon - The Apache Server Framework *****
>
> Bold statement indeed, but apparently not bold enough, as
> Avalon has outgrown this statement, and some say it should
> now fit inside anything from an credit card to an airline
> booking system (exaggeration intended) and preferably without
> any differentiation of codebase. It should be tweakable to
> fit inside any other technology out there, without any
> demands placed on that technology, and ohh..., throw in some
> GUI applications as well.
>
> This has gone completely out of proportions. Face it, what is
> the bottom line purpose of Avalon or ANY other OSS project;
>
> ***** To serve our users *****
>
> and not to serve our egos, or the academic research paper on
> ultimate scalability that will earn my doctor's degree.
>
> - o - o - So what are our Users' needs?? - o - o -
>
> Well, to answer that question, we need to look at WHO is our users?
>
> Traditionally, we have always turned to Cocoon, Turbine and
> James, but are they truly the real users, and are they really
> the main beneficiary of Avalon.
>
> If the answer to this is YES, then the future direction of
> Avalon is very simple, shut down Merlin and Fortress, and
> continue to evolve ECM and Phoenix. As Mr Sutic explains
> "migrating to Merlin would not translate into a single $ for
> me" and conclude that migrating away from ECM for Cocoon
> doesn't solve anything per se, only a hope that the next
> container will come up with something better for them in the long run.
>
> - o - o - Are our users Cocoon, Turbine and James??? - o - o -
>
> I think NO, they are part of our user base, but they are not
> even the main beneficiary of Avalon technology.
>
> - o - o - How can that be? - o - o -
>
> Projects like these three are large, independent and
> basically don't have any commercial constraints. There is
> very little **re-use** involved !!
>
> Face it! The real beneficiaries are all those developers out
> there, who crank out 2-5 applications a year, often within
> the same problem domain, for different customers. All are
> slightly different, but the bulk is **re-use**.
> The developers who currently use copy-paste to move from
> project to project, are the ones who can really get a
> performance boost out of COP, NOT the large monolithic
> product developers.
>
>
> Stephen mentioned to me something in the region of a 1000
> downloads of Merlin a day. If that is true, it is a shame we
> don't manage to attract many of them to stay on (which can be
> seen on user@ if anyone reads it). I think the reasons are;
>
> 1. "Which container?"
> 2. Too few components.
> 3. No documentation of the components that do exist.
> 4. It is unclear what the benefits for the corporate
> developer are, when hitting the official website.
> 5. We are not "political correct".
>
>
> - o - o - The Way Forward - o - o -
>
> Avalon and its community have a lot of choice, and need to
> make decisive
> action, or it will become a dead project and laughing stock
> of the ASF.
>
> * Absorb a Unifying Vision (see separate post later).
>
> * Drop the concentration on container toolkit, support of IoC
> types, and
> similar academic issues. Those interested in these exercises
> can and already
> do this outside this community, which is fine, but let's not
> get divided over
> things that doesn't matter to our emerging users.
>
> * Declare Merlin * The Apache Server Framework *, and create
> easy access to
> the 2-4 common usecases that really exists, not constructed
> ones to prove
> versatility for the academic sake. Transfer ECM to Cocoon. Deprecate
> Fortress, or those who are interested bring it elsewhere.
>
> * Focus on component contracts and patterns, which will help
> the corporate
> developer and reusability at large. Flexibility is not
> performance improving,
> and please search the Cocoon mail archive for the word "Flexibility
> Syndrome". I want to solve real problems for real people !
>
> * Evolve Merlin to support these new solid contracts.
>
> * Bring MerlinDeveloper to market for rapid prototyping solutions.
>
> * Bring a component publishing infrastructure product into
> existence, to
> simplify the component publishing for non-ASF committers.
>
>
> - o - o - Conclusion - o - o -
>
> Avalon needs to get a momentum forward, and I will produce
> the Unifying Vision
> in a separate post. Stalemate and in-fighting brings us nowhere.
> Avalon has, like Cortez, sailed a long way and there is a
> jungle of obstacles
> in front. Burn the ships!!! Move forward, there is no going
> back. Those who
> want to peddle around with petty things, stay on the beach
> and pamper ECM,
> Phoenix and Fortress. The rest of us, who want to conquer new
> land, will
> forge ahead for fame and fortune (God, King and Country if
> you prefer :o) ).
>
> Staying on the beach will lead to death in obscurity, without
> anyone caring
> about it.
>
>
> Niclas
>
> --
> +---------//-------------------+
> | http://www.bali.ac |
> | http://niclas.hedhman.org |
> +------//----------------------+
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Purpose of Avalon
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> On Wednesday 10 March 2004 18:38, Leo Sutic wrote:
> > since I motivated my criticism with "no $ for me", just what do you
> > think I do all day? Write academic papers?
> >
> > Frankly, what do you think most of us do all day?
>
> I wasn't referring to you, and if you somehow believe I did,
> I apologize.
I didn't. I did however think that you referred in general to
people on the list. Since you first held up viewpoints other than
your own, and then went on about not satifsying our egos but our
users, the second part sort of got tangled up in the firt part in
my head.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Purpose of Avalon
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 10 March 2004 18:38, Leo Sutic wrote:
> since I motivated my criticism with "no $ for me", just what
> do you think I do all day? Write academic papers?
>
> Frankly, what do you think most of us do all day?
I wasn't referring to you, and if you somehow believe I did, I apologize.
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Purpose of Avalon
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> The real beneficiaries are all those developers out
> there, who crank out 2-5 applications a year, often within
> the same problem domain, for different customers.
Niclas,
since I motivated my criticism with "no $ for me", just what
do you think I do all day? Write academic papers?
Frankly, what do you think most of us do all day?
I find it a little puzzling that you'd blast what is being
done as "academic", when you only need to look at yourself
to realize that almost all users of the framework are
professional developers, and not here to satisfy our egos
but our real-life customers.
My point with all this is that perhaps you should scale down
on the rhetoric.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org