tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cmanola...@yahoo.com>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina Container.java
Date Sat, 10 Nov 2001 00:25:34 GMT
There are 2 different issues here:

1. Major decisions, major actions. For 3.x - it was discussed ( so many
times ) that the API in 3.0 was bad, so it had to change. And it was
discussed and agreed ( AFAIK ) that the API in 3.3 is 'good enough' and
it shouldn't change. And all major changes were discussed or at least
announced ( Nacho's new class loader, JspInterceptor, MessageBytes, etc ).

For 4.0 - do we thing the API is ready ? Then it should remain backward
compatible. No - then we should find what's broken and fix it.

I have no problem with any - but I haven't seen any discussion about
this so far. In fact I have no idea what's happening with 4.1 - what
does it want to do and why ? If 4.0 APIs are ready then the modularity
goal is reached and we don't need any more changes - just new modules,
and that can be done without requiring a new dot version.

The admin app is another case of major decision that lacked any
meaningfull discussion.

2. SocketFactory and normal development. That's easy, if we decide
'backward compatible' - it's a trivial bug to fix, if we decide
'new API' - everything is fine the way it is ( and we need to support
one more API in jk )


I'm not complaining against refactoring, but against lack of
communication. I'm not complaining against new and usefull features -
but against implementing them the wrong way, without participation
and discussion.


Costin




On Fri, 9 Nov 2001, Craig R. McClanahan wrote:

> I would suggest looking back at all the backwards-incompatible API changes
> that were done as part of the 3.x refactoring process (3.0 --> 3.3).  They
> fall into three categories:
>
> * Discussed ahead of time (and/or proposed with lazy consensus).
>
> * Committed and then accepted (lazy consensus) or refined based on
>   feedback.
>
> * Just committed, even if they broke old code.
> All three happened, in significant percentages of cases, in 3.x (the
> reason that "org.apache.catalina.util" existed in the first place is
> because I got tired of Costin's changes breaking Catalina builds that
> depended on "org.apache.tomcat.util" in the early days :-).  But the more
> important point is that all three will *always* happen, unless we're
> willing to slow things way down.
>
> Arbitrary changes that break things are, in general, not ideal.  That's
> what deprecating old interfaces is about (This got lots better later in
> the 3.x process, for example).  If ServerSockeFactory doesn't compile
> against the 4.0 branch, despite my attempt to leave a deprecated version
> of the old class name, that's a bug in my deprecation, not a malicious
> attempt to be incompatible.  It should be treated like any other bug.
>
> On the other hand, refactoring by its very nature changes things (which is
> why I'm smiling when I think about who is complaining here :-).  We have
> to balance need/desire for improvement, maintaining APIs in exsting code
> (even if it's not in the same package), readability, and all the other
> usual pile of motivations for changing things.
>
> >
> > Costin
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message