tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <rmauch...@home.com>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina Container.java
Date Sat, 10 Nov 2001 09:17:41 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.

Obviously, there are/were still some omissions and small problems.

> 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.

You can always improve and refactor, so the core won't stay frozen.
According to what I've seen so far, the admin stuff and the JMX features are
modules, as well as the updated connectors, so almost everything will be
modules. People may want to see hype-friendly version numbers, so I suggest
we increment the second digit, even if what we call 4.1 is in fact 4.0.3 +
tons of new modules. Does it make sense ?

> 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 )

Leaving that deprecated interface around doesn't look very fancy to me.

Remy


--
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