tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina
Date Sat, 10 Nov 2001 17:59:45 GMT
On Sat, 10 Nov 2001, Remy Maucherat wrote:

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

Well, it's not that obvious. I have seen little discussion on what's
broken and how to fix it - and I remember reading in some mails that 4.1
will be 'backward compatible with 4.0' - which implied the reverse ( i.e.
the 4.0 API is 'good enough' and will not change ).

IF ther are only 'few omissions and small problems' - then it's even less
obvious. Are those small enough that we can accept them as a price for
stability ? This is not something you can take as 'obvious'.

As you know I don't like the 4.0 API - I think it's far too complex,
but I can accept some people like it - I'm not going to vote one
way or another, but I want to know that this issue was decided
( for example mod_jk has 'facades' to 3.3 and 4.0, and we may need
to add another facade for 4.1 if this is not going to be compatible
with 4.0 )

> You can always improve and refactor, so the core won't stay frozen.

If the problems are 'few and small' - I can't see why ? For example
a number of people consider the current API in 3.3 to be good enough,
and that improving it is less valuable than keeping it stable.

I love refactoring - as long as it has a start and an end and you
have a clear target and know what is broken and how to fix it.

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

No, it doesn't.

It could make sense if the API would be backward compatible and the
modules would be clearly separated.

But even then - what if you want to make a major API change ? You can't
call it 5.0 ( since that would imply servlet 2.4 ).

So far the first number indicate the servlet API, the second is the
'major version number'. I believe you need a way to indicate
major changes, and the second digit is the only one available.

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

But is _required_ if people decide on backward compatibility.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message