You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2002/04/26 21:34:55 UTC
Re: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add collecting
of statistics to pool implementations)
On 4/26/02 2:54 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> I have tried myself to make projects cooperate on Jakarta, and there are
> cases in which one part simply refuses to do it.
>
> This is the reason why there are duplicate projects, and why projects keep
> making subprojects that have less an less to do with the original project.
That's *one* reason why. Sometimes just taking a different path to
solutionof the problem is the reason, and that's good enough.
(See Turbine + Struts)
> It seems to me, and to many outside viewers, that there is a sort of anarchy
> in the way subprojects are created, making code duplication a reality.
Which I think has some very positive qualities.
> There is not a unified vision, if not the Apache license and the "server"
> mission.
Indeed.
> I can live with this, and I see that it can bring good things. If projects
> compete, they can benefit from each other, since the source is there to see
> and the license permits it.
>
> The downside is how we are seen from the outside...
>
> -oOo-
>
> IMHO Jakarta should favor the use of common interfaces.
No. I think subprojects should do whatever the participants in the
subproject decide. If there is a compelling set of interfaces or components
and they wish to use them, that's great. If not, that's great.
> Interfaces can become standards, and this is how Apache can create
> "de-facto" APIs.
>
> This way projects can give the user functionality without locking him into
> their API for common functionality.
>
> What about *Commons-API*?
>
Kinda smells like a framework. :)
We have a de-facto commons API. That's what the components are, all
independent, and the overlap in the community means that there tends to be
quite a bit of interdependence between them, which strengthens those that
seem to work well.
So I would say that in a sense, we already have one.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"We will be judged not by the monuments we build, but by the monuments we
destroy" - Ada Louise Huxtable
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add collecting of statistics to pool implementations)
Posted by Paulo Gaspar <pa...@krankikom.de>.
> I think Costin's points are valid, but am not of the belief that just
> because there are good sides to duplication that the bad sides shouldn't
> be attempted to be dealt with.
Of course - I also suggested something on that direction.
I just think that you can not and should not force people away from any
duplication but I agree with other measures that help avoiding those bad
sides.
If people are a bit pushed into knowing well the previous/concurrent
versions of the wheel they are trying to reinvent and if the potential
user is made aware of the alternatives the situation can get much better.
Have fun,
Paulo
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Sunday, April 28, 2002 11:36 PM
>
> On Sun, 28 Apr 2002, Paulo Gaspar wrote:
>
> > For this kind of issue, Jon's traditional answer is:
> > - Are you volunteering?
>
> Will have to see how itchy the itch gets.
>
> I think Costin's points are valid, but am not of the belief that just
> because there are good sides to duplication that the bad sides shouldn't
> be attempted to be dealt with.
>
> Hen
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add collecting
of statistics to pool implementations)
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 28 Apr 2002, Paulo Gaspar wrote:
> For this kind of issue, Jon's traditional answer is:
> - Are you volunteering?
Will have to see how itchy the itch gets.
I think Costin's points are valid, but am not of the belief that just
because there are good sides to duplication that the bad sides shouldn't
be attempted to be dealt with.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add collecting of statistics to pool implementations)
Posted by Paulo Gaspar <pa...@krankikom.de>.
For this kind of issue, Jon's traditional answer is:
- Are you volunteering?
The problem is that this is a volunteer organization. One can not just
appoint someone to do something - the person that does it must want to
do it.
So, if you want something to be fixed, you must be willing to do it.
I know better than the average the complete range of components
available at Jakarta projects and even in Cocoon, but I do not have
the patience to do the systematic and boring job of comparing them and
write down the conclusions... and that is the reason why I do not ask
someone else to do it.
What I try to do is to tell someone that is reinventing the wheel
where he can find the code for former wheels.
The only solution I see for this issue is to rule that a project
duplicating functionality existing on a previously existing project
should only be approved if it documents the differences and the older
project should cross link to that document.
Of course that this is not so simple and that the older project
should have the opportunity to review and push changes to that
document and so on.
Still, this kind of rule would force awareness of similar projects
and possibly improve cross-pollination.
Costin already wrote a very interesting mail on this thread about
the reasons and positive effects of duplication. Of course that for
several of those effects to work it helps that there is some dialog
going on between the members of those "duplicated" projects.
One possible example of such positive effects might be Avalon's
Excalibur project. They recently made an impressive reorganization
of their code and web pages and, IMHO, that raises the bar in terms
of their competition with the Commons.
This can only be good:
- It is now easier for a the user to pick an isolated Excalibur
component;
- That former difficulty was one of the reasons for duplicating
or even just not looking at those components.
So, Excalibur improved due to the pressure of the Commons.
Now it is even possible that some components will be merged or
some duplication will die (although I am not betting on it). But
more important is that Excalibur now starts looking much better
organized than the commons - which is a positive point favoring
the use of their components - because:
- More homogeneous organization of each component code;
- Better average/minimum documentation.
Maybe now the Commons will improve those aspects!
(At least I can hope...)
=;o)
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Sunday, April 28, 2002 6:11 AM
> To: Jakarta Commons Developers List; paulo.gaspar@krankikom.de
> Subject: RE: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add
> collecting of statistics to pool implementations)
>
>
>
> On Sat, 27 Apr 2002, Paulo Gaspar wrote:
>
> > And I don't give a shit about how it looks to the outside
> > because:
> > - This is not a commercial organization;
> >
> > - If we have a specific target audience, it is a technical one
> > that makes a well informed choice... or they would be
> > flocking toward organizations with a more corporate look and
> > culture.
>
> Given two projects which are duplicating effort, such as Commons/Excalibur
> or all the DBCP-style components, or a project such as mod_webapp/jk where
> the older version is still in development, I think it is important for
> there to be documentation concerning the difference.
>
> To be saying to developers/users of the code that these things do the same
> and you should probably just look at the functionalities to see which you
> think is best, read the archives to see which you think is still worked
> on, most stable, has the best direction, is a pretty poor service.
>
> Jakarta has long maintained two Regexp engines, and when you read the
> documentation there is a part (I'm not sure if both have it) which
> explains why there are two, which is better for which situation, and which
> is still being improved.
>
> This documentation is difficult to make, who is sitting in the middle
> enough to write a good view, but is sorely needed. When I went looking for
> the latest mod_jk and discovered mod_webapp it was very hard to discern
> what their roles were. I believe because jk had just had a release.
>
> Hen
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add collecting of statistics to pool implementations)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: <co...@covalent.net>
> On Sun, 28 Apr 2002, Henri Yandell wrote:
>
> > Given two projects which are duplicating effort, such as
Commons/Excalibur
> > or all the DBCP-style components, or a project such as mod_webapp/jk
where
> > the older version is still in development, I think it is important for
> > there to be documentation concerning the difference.
>
> I think there is a different way to look at all this duplication.
<snipped-great-description/>
> People are more important than code.
>
> Costin
I think that this is the best explanation so far of the code duplication
benefits.
While I agreed on this even before, I thought that maybe uniform APIs with
different background implementations could help the user while keeping code
duplication.
Now I think I was wrong, since the APIs are integral part of any program,
and benefit themselves from reasonable duplication.
Costin, could you please put this up on the Jakarta site?
I would use it as a link for anybody that complains of code duplication; I
could never explain it better myself.
--
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: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add collecting
of statistics to pool implementations)
Posted by co...@covalent.net.
On Sun, 28 Apr 2002, Henri Yandell wrote:
> Given two projects which are duplicating effort, such as Commons/Excalibur
> or all the DBCP-style components, or a project such as mod_webapp/jk where
> the older version is still in development, I think it is important for
> there to be documentation concerning the difference.
I think there is a different way to look at all this duplication.
We are a community-driven organization - a group of people,
many are very smart and with powerfull ( sometimes unsupportable )
personality.
This results in a lot of creativity and experiments and frictions
and politics - it's a mixed bag.
Some people believe mod_webapp has a better design and serve their
needs better, while mod_jk sucks. Some other people believe the reverse.
Same is true for crimson/xerces1, tomcat3/4, turbine/struts, and each pair
of components that have similar goals - but different community.
That won't make the new component better or 'replace' the old one.
Pier is a great programmer, and he certainly have great ideas - but
there are many good programmers who worked and are working on jk, and the
end result depends only on the community that each component forms.
As long as Pier doesn't like mod_jk ( for whatever reason - he
may be very right ) - having him work on webapp is benefical for
everyone. No management or rule can force him to spend his free
time on some code he doesn't like - and the code/ideas he puts
in webapp may serve a user base and will also help jk.
I like jk, and quite few other people do the same. I respect Pier,
but that doen't mean I agree with his opinions. As long as he
(and other ) are interested, mod_webapp will live along. Maybe
someday we'll merge the code, we certainly merge ideas back and
forth - maybe not.
People are more important than code.
Costin
>
> To be saying to developers/users of the code that these things do the same
> and you should probably just look at the functionalities to see which you
> think is best, read the archives to see which you think is still worked
> on, most stable, has the best direction, is a pretty poor service.
>
> Jakarta has long maintained two Regexp engines, and when you read the
> documentation there is a part (I'm not sure if both have it) which
> explains why there are two, which is better for which situation, and which
> is still being improved.
>
> This documentation is difficult to make, who is sitting in the middle
> enough to write a good view, but is sorely needed. When I went looking for
> the latest mod_jk and discovered mod_webapp it was very hard to discern
> what their roles were. I believe because jk had just had a release.
>
> Hen
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add collecting
of statistics to pool implementations)
Posted by Henri Yandell <ba...@generationjava.com>.
On Sat, 27 Apr 2002, Paulo Gaspar wrote:
> And I don't give a shit about how it looks to the outside
> because:
> - This is not a commercial organization;
>
> - If we have a specific target audience, it is a technical one
> that makes a well informed choice... or they would be
> flocking toward organizations with a more corporate look and
> culture.
Given two projects which are duplicating effort, such as Commons/Excalibur
or all the DBCP-style components, or a project such as mod_webapp/jk where
the older version is still in development, I think it is important for
there to be documentation concerning the difference.
To be saying to developers/users of the code that these things do the same
and you should probably just look at the functionalities to see which you
think is best, read the archives to see which you think is still worked
on, most stable, has the best direction, is a pretty poor service.
Jakarta has long maintained two Regexp engines, and when you read the
documentation there is a part (I'm not sure if both have it) which
explains why there are two, which is better for which situation, and which
is still being improved.
This documentation is difficult to make, who is sitting in the middle
enough to write a good view, but is sorely needed. When I went looking for
the latest mod_jk and discovered mod_webapp it was very hard to discern
what their roles were. I believe because jk had just had a release.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add collecting of statistics to pool implementations)
Posted by Paulo Gaspar <pa...@krankikom.de>.
I completely agree with Geir.
IMAO, what is bad is when people in a project ignore (sometimes
deliberately) all prior art and even newer ideas about the same
subject that their project covers.
But duplication as many advantages. Different styles, different
choices.
And I don't give a shit about how it looks to the outside
because:
- This is not a commercial organization;
- If we have a specific target audience, it is a technical one
that makes a well informed choice... or they would be
flocking toward organizations with a more corporate look and
culture.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Friday, April 26, 2002 9:35 PM
> To: Jakarta Commons Developers List
> Subject: Re: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add
> collecting of statistics to pool implementations)
>
>
> On 4/26/02 2:54 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> >
> > I have tried myself to make projects cooperate on Jakarta, and there are
> > cases in which one part simply refuses to do it.
> >
> > This is the reason why there are duplicate projects, and why
> projects keep
> > making subprojects that have less an less to do with the
> original project.
>
> That's *one* reason why. Sometimes just taking a different path to
> solutionof the problem is the reason, and that's good enough.
>
> (See Turbine + Struts)
>
> > It seems to me, and to many outside viewers, that there is a
> sort of anarchy
> > in the way subprojects are created, making code duplication a reality.
>
> Which I think has some very positive qualities.
>
> > There is not a unified vision, if not the Apache license and
> the "server"
> > mission.
>
> Indeed.
>
> > I can live with this, and I see that it can bring good things.
> If projects
> > compete, they can benefit from each other, since the source is
> there to see
> > and the license permits it.
> >
> > The downside is how we are seen from the outside...
> >
> > -oOo-
> >
> > IMHO Jakarta should favor the use of common interfaces.
>
> No. I think subprojects should do whatever the participants in the
> subproject decide. If there is a compelling set of interfaces or
> components
> and they wish to use them, that's great. If not, that's great.
>
> > Interfaces can become standards, and this is how Apache can create
> > "de-facto" APIs.
> >
> > This way projects can give the user functionality without
> locking him into
> > their API for common functionality.
> >
> > What about *Commons-API*?
> >
>
> Kinda smells like a framework. :)
>
> We have a de-facto commons API. That's what the components are, all
> independent, and the overlap in the community means that there tends to be
> quite a bit of interdependence between them, which strengthens those that
> seem to work well.
>
> So I would say that in a sense, we already have one.
>
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> "We will be judged not by the monuments we build, but by the monuments we
> destroy" - Ada Louise Huxtable
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>