tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: Review model take 2
Date Thu, 20 Sep 2007 15:27:01 GMT
On 9/20/07, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:

> well, we have the annotation changes needed for geronimo, that were not
> allowed in 6.0
> personally, I think that was enough to keep trunk alive.
> Let's say that I did have a huge architecture change, lets say, I want
> to swap out ByteChunk/CharChunk for ByteBuffer/CharBuffer and also use
> nio charset conversion,
> then doing that in trunk is not so appropriate either. So I will do that
> in sandbox, the right place for an experiment like that. Maybe it turns
> out that it worked perfectly, and we want to put that into Tomcat, we
> can't put it in 6.0, that would be insane, and we don't have a trunk, so
> where do we put it?


For ByteChunk -> NIO - it's clearly an API chnge, so according to the new
proposal ( that seems to have a large enough majority and got clarified in
many
ways - probably can be put to a formal vote ): RTC. If a majority ( at least
3 +1,
more +1 than -1 ) think this should be done - we can discuss if this is big
enough to move from 6.0 to 6.5 ( I think it is - because will change a lot
of APIs ),
or if there are way to keep the old API working alongside with a new one (
backward
compatibiliy is quite important ).

Alternative answer: since the connector interface is heavily using
ByteChunk, you may
start it as a separate package from coyote ( nio-coyote ? ), add hook points
so you
can use nio-coyote connectors at the same time with coyote ones. Most of the
work
can be CTR, in 6.0 ( maybe a 'modules/' directory ). I'm not sure if this is
technically
feasible due to deps - but if I a vote comes up, I would vote for a proposal
that preserves
backward compat, and -1 if all existing connectors need to be rewritten.

For the others - again, you have the choice to implement them as a plugin,
CTR. If
it needs API/core changes - those need to be RTC and get majority. IMO if
you want
it done - minimizing API changes and doing most of the work in a component
has bigger
chances, but it's your proposal :-)

In all cases - it's a simple vote to decide if an API change or core
features gets in using RTC rules.
And it's also a simple vote to move from 6.0 to 6.5 ( and freeze 6.0 - all
new code/changes will go to 6.5 ).



Removing trunk, pretty much halted any chances for future innovation, as
> approved sandbox experiments have nowhere to go.


6.0 is really the place where active development on tomcat should happen
until a 6.5 proposal
is passed, so that's the real trunk ( no matter how it's called ).

The only issue is that "innovation" that affects API or core should be RTC -
i.e. requires
more than one person making arbitrary changes ( that may be valid and good -
but as with
any API change should be more controlled and have more support than a simple
'it works' )
And again - it's a simple  vote to go either way, no need to fight or take
it personally -
every person has a different (and valid) opinion and may want to do things
his (better) way,
but needs to give up a bit for the sake of the others.

Costin

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message