You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/06/14 17:47:09 UTC
[vote] design constraint #0 for Avalon 5
Hi everyone,
I would like to have your vote on this design constraint on Avalon 5:
all possible efforts should be done to avoid avalon forking
The rationale behind this is *very* simple:
if you make it *harder* to use Avalon and you simply use elegance
reasons, people won't follow you and keep what they have. Then, needs to
change emerge and two different branches are setup.
This is bad enough for applications (see Tomcat 3.x vs Tomcat 4.x or Ant
1.x vs Ant 2.x) but it would be *terrible* for APIs, it would simply
kill the project.
When you are designing something new, you must make it appealing for old
users to switch, because that take time energy and effort.
Many of the proposals I've see so far go toward the 'elegance cleanup'
direction and very few to the 'usability/functionality' direction.
If we keep this direction, nobody will switch to Avalon 5, they will
simply keep on patching Avalon 4 and all our effort is useless.
So, what do you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] design constraint #0 for Avalon 5
Posted by Leo Simons <le...@apache.org>.
> I would like to have your vote on this design constraint on Avalon 5:
>
> all possible efforts should be done to avoid avalon forking
and I would add: all possible efforts should be made to remove the need
for avalon forking.
> When you are designing something new, you must make it appealing for old
> users to switch, because that take time energy and effort.
and make it cost as little time, energy and effort to actually switch.
> Many of the proposals I've see so far go toward the 'elegance cleanup'
> direction and very few to the 'usability/functionality' direction.
>
> If we keep this direction, nobody will switch to Avalon 5, they will
> simply keep on patching Avalon 4 and all our effort is useless.
I question whether we are going in that direction =)
> So, what do you think?
+1. I think we are all on the same page here, even if it is not so clear
from previous discussions.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] design constraint #0 for Avalon 5
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Hi everyone,
>
> I would like to have your vote on this design constraint on Avalon 5:
>
> all possible efforts should be done to avoid avalon forking
>
> The rationale behind this is *very* simple:
>
> if you make it *harder* to use Avalon and you simply use elegance
> reasons, people won't follow you and keep what they have. Then, needs to
> change emerge and two different branches are setup.
>
> This is bad enough for applications (see Tomcat 3.x vs Tomcat 4.x or Ant
> 1.x vs Ant 2.x) but it would be *terrible* for APIs, it would simply
> kill the project.
>
> When you are designing something new, you must make it appealing for old
> users to switch, because that take time energy and effort.
>
> Many of the proposals I've see so far go toward the 'elegance cleanup'
> direction and very few to the 'usability/functionality' direction.
>
> If we keep this direction, nobody will switch to Avalon 5, they will
> simply keep on patching Avalon 4 and all our effort is useless.
>
> So, what do you think?
I agree *TOTALLY*.
This is what I was (albeit /very clumsily/) trying to do with my last
vote-rant mail.
Reading the mails of the last days, I think that implicitly we all agree.
Let's not forget it :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] design constraint #0 for Avalon 5
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> At 05:47 PM 6/14/2002 +0200, you wrote:
> >Hi everyone,
> >
> >I would like to have your vote on this design constraint on Avalon 5:
> >
> > all possible efforts should be done to avoid avalon forking
>
> Avalon has already been forked.
Definition of fork: when you have two projects with different
communities, with a complete overlap between the two.
Examples: FreeBSD vs. NetBSD, Emacs vs. XEmacs, Tomcat 3.x vs. Tomcat
4.x
Using this terminology, Avalon has not (yet?) been forked.
> There is a whole bunch of stuff in there
> that was added in for Cocoon that is not used anywhere else.
All the avalon classes that we ship in Cocoon are those hosted on the
avalon CVS, with no changes whatsoever. An extension is not a fork.
> A5 will unify
> the model or else it wont occur at all. A4 may not be perfect but it is
> definelty good enough for me. The problems with it are due to misuse of
> features and lack of unified metadata or container utilities.
I agree with you 100%. I would like to see more unification of the
different avalon containers and component metadata and various
utilities. Still, I haven't find a 'plan' that outlines what the
problems are: I was just called to judge the solutions.
> Metadata support is underway and hopefuly will ease that pain. Container
> utilities are also on the way and hopefully that will encourage people to
> not misuse features (by not natively supporting them).
Yes, this is a good migration path.
> >So, what do you think?
>
> It is a good idea. However if anyone was to try and force usage patterns
> that result from a specific container - especially when those usage
> patterns could be considered problematic then I think it wont work.
Agreed. But 'problematic' must be stated with precision and with
openmindness. Stating that ComponentNotFoundException is a system
exception and if you use it differently you are wrong, is not, IMO,
stating any problems, but just a personal esthetic vision. (which I
personally happen to resonate with, for what's worth, but I'm not the
cocoon-dev community, I'm just one of them)
> I have looked at all the containers and believe I know where we can
> continue to work together but there are somethings there will need to be
> compromises from all.
Absolutely. I'm here to make sure those compromises are reached.
> However when I hear predictions of Doom and
> ultimatims I find myself thinking A4 is going to be about for a long time
> yet ;)
For sure it will take long time for the migration, no matter how hard we
try.
A5 might not happen at all because of social issues (nothing technical
at all). I simply wanted to raize the issue.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] design constraint #0 for Avalon 5
Posted by Peter Donald <pe...@apache.org>.
At 05:47 PM 6/14/2002 +0200, you wrote:
>Hi everyone,
>
>I would like to have your vote on this design constraint on Avalon 5:
>
> all possible efforts should be done to avoid avalon forking
Avalon has already been forked. There is a whole bunch of stuff in there
that was added in for Cocoon that is not used anywhere else. A5 will unify
the model or else it wont occur at all. A4 may not be perfect but it is
definelty good enough for me. The problems with it are due to misuse of
features and lack of unified metadata or container utilities.
Metadata support is underway and hopefuly will ease that pain. Container
utilities are also on the way and hopefully that will encourage people to
not misuse features (by not natively supporting them).
>So, what do you think?
It is a good idea. However if anyone was to try and force usage patterns
that result from a specific container - especially when those usage
patterns could be considered problematic then I think it wont work.
I have looked at all the containers and believe I know where we can
continue to work together but there are somethings there will need to be
compromises from all. However when I hear predictions of Doom and
ultimatims I find myself thinking A4 is going to be about for a long time
yet ;)
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>