On Thu, 21 Dec 2000, Rob S. wrote:
> Correct me if I'm wrong, but maybe the whole focus of 3.3 / 3.2.x thing, is
> that neither of them will be all that they could be because the resources
> are so limited and divided.
About the same resources that made the evolution from 3.1 to 3.2 are
available and working for 3.3.
3.2.x are maintainance releases - i.e. minor bug fixes or security issues.
You can't and shoulnd't do any serious change ( like rewriting of the
cookie handling, or reduce the use of Strings, or the refactoring that is
still needed ).
There is no difference AFAIK between 3.1->3.2 and 3.2->3.3 ( except that
for 3.1 we didn't had a 3.1.x until recently )
Keep in mind that "resources" are not mind-less kids that work on what
the "grown-up" people tell them to do - most open source developers I know
can decide for themself what they want to do, and express that in doing
what they want of they are allowed to.
> Of what value would enhancing JServ to the point of technical perfection, be
> right now when it is clearly not the direction things are headed? To me, if
> someone said, "i want to make all these great changes to JServ" I'd be like,
> "ok sure, but no one is going to use it since it's old school. Why not help
Yet I don't think you have the right to stop him - it's his time, and this
is open source. We are in fact still reusing and enhancing JServ code (
mod_jserv is still used in tomcat3, and mod_jk is based in part of that
code ).
> out the people on 3.2.x or 4.0?" HOWEVER! 3.1 and 3.2.1 are being used by
> LOTS of people, so lots of people would benefit by releasing a killer 3.2.x
> or 3.3 or 3.9 as Pier puts it. In this regard, I can totally agree with the
> general idea of "making 3.2.x better!"
We could easily re-do all the changes that we did in 3.3 using the 3.2.x
numbers - yet it'll be a lie. The difference between 3.2 and 3.3 may be
slightly smaller than 3.1 and 3.2, but it's still big and significant
enough.
( many of the changes in 3.3 were moving code around changing the
representation of request info from String to MessageBytes. The rest is
removing deprecated code and adding comments and removing ambiguous
behavior ).
> But, and forgive me if everyone understands and realizes this, all of these
> changes will come at a price - namely slower development of the agreed-upon
> "future of Tomcat." If committers didn't think TC 4.0 was the future, and
> didn't want to work on, then why all of the +1s?
It doesn't look at all like "agreed-upon future of tomcat" - yes, we had a
vote to implement servlet2.3 in TC4.0, and there was no -1 on the vote.
And it was the right decision - nobody should -1 alternate ideas ( I
learned that very late, as you know one year ago I was fighting against
catalina and revolutions ).
If you look at the commits that went into 3.3 and read this mailing
list carefully, you'll notice that there are developers who think that the
future is decided by code commits and real contributions.
( in any case, strictly speaking there is no 4.0 and no 3.3 - you can't
vote or decide on something that doesn't exist, and so far both of them
are in work. )
> As well, there will be less time for the necessary bug fixes and performance
> enhancements for the 3.2.x line, the introduction of even more bugs that are
Most of the bug fixes and performance enhancements of the 3.2 line are
made in 3.3. That's what happened after 3.1, that's what happened after
3.0.
BTW, most of the performance enhancements that went into 3.3 existed
_before_ 3.2 was released ( and some were actually implemented and ready
to go). I felt at that time that it's better to postpone them in order to
shorten the release cycle - it is my belief that too long release cycles
are bad for an open source project.
That's one of the reasons I tried as hard as possible to make sure that
tomcat3 can be developed in a modular way, with independent cycles for
each module. In order to do that we need the modularity that is result of
refactoring and reorganization done in 3.3.
> but with more bugs (because the old ones are there while all of the new
> changes were taking place, and the newly-introduced ones as well). So how
That's again wrong - some of the bugs in 3.2 can't be fixed without
serious changes in the code. AFAIK most commits from 3.2 tree are or will
be merged into 3.3, and I think a number of bugs were fixed as a result of
refactoring ( my example is Cookies - the parser in 3.2 supported only
v0 cookies, and sent the wrong header for v1 cookies ).
> So at the end of all of this, we have slowed development of 4.0 while we end
> up with a functionally equivalent container to 3.2.1, but with more bugs,
3.3 is based on 3.2 - and bug fixes for 3.2 are bug fixes for 3.3 as well.
> This also goes back to a philosophical question - How many big "changes"
> (architectural or not) before someone is "happy" with the code? I worked
> with a developer who chronically rewrote the things he worked on "to get
> them perfect." As a result, he never progressed, continually outputting
> things that were functionally identical, just written differently. Do the
> end-users care? Nope. Even for a 5-10% performance enhancement? Who's to
> say...
As I said, I think 3.3 will be a reasonable compromise - it will not be
perfect, but good enough. IMHO 3.2 is not - for many reasons ( even that
fact that all deprecated code is still there ).
We are not talking about 5-10% performance enhancements - but 2x or
3x. Performance is good, but in this case it's not the main
factor. Modularity is.
> Anyways, just my 2c. I don't really care who does what or when or whatever,
> or how perfect the code is or what. "I want" a container NOW that has very
> little bugs, and works the way it should (adheres to the spec, etc.).
> Personally, I don't care if it's spaghetti or what, so long as when I
> install it, it's easy to configure, does what it should, and does it well.
This is a reasonable opinion, and I agree with most of it. But for people
who are developing the container it is important to have reasonably good
code ( not perfect ).
Costin
