Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs

["Christopher K. St. John" <ck...@distributopia.com>]

 Ok, second round.

 People are +1'ing the _goals_ of the proposal, but I
the proposal itself doesn't give sufficient detail to
determine if the recommended actions will actually 
lead to those goals being accomplished.

 Some of the goals even appear to be contradictory,
but there's no discussion of the inevitable engineering
tradeoffs. Simplicity vs Flexibility is a big issue.

 For example, the Coyote framework is compatible with
Tomcat 3 and Tomcat 4. This is admirable, and may lead
to closer ties between the two groups of developers.

 BUT Coyote is also more complicated and harder to
understand than the HTTP connector code in Tomcat 4 that
it replaces. It does more, too, but let's face it, it's
an integrated framework for writing connectors, and
frameworks are harder to understand and build than
single-purpose code.

 That isn't to say it wasn't worth it, but you've gone
from only needing to understand o.a.c.connector to having
to understand a whole slew of packages and patterns and
conventions. There's more buy-in required.

 I'd like to see considerably more discussion about
tradeoffs before the proposal is approved.


-- 
Christopher St. John cks@distributopia.com
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs

[Remy Maucherat <re...@apache.org>]

Christopher K. St. John wrote:
>  Ok, second round.

Ok, one last time.

>  People are +1'ing the _goals_ of the proposal, but I
> the proposal itself doesn't give sufficient detail to
> determine if the recommended actions will actually 
> lead to those goals being accomplished.
> 
>  Some of the goals even appear to be contradictory,
> but there's no discussion of the inevitable engineering
> tradeoffs. Simplicity vs Flexibility is a big issue.
> 
>  For example, the Coyote framework is compatible with
> Tomcat 3 and Tomcat 4. This is admirable, and may lead
> to closer ties between the two groups of developers.
> 
>  BUT Coyote is also more complicated and harder to
> understand than the HTTP connector code in Tomcat 4 that
> it replaces.

This is untrue.

The old Tomcat 4 HTTP/1.1 connector is a good example of spaghetti code. 
It works (99% of the times, at least; Pier found the last 1%), but I 
defy you to explain to me how chunking is determined, how it works, and 
how it actually produces the chunks in one single unified buffer, using 
an object hierarchy three levels deep in the process.

Coyote HTTP/1.1 is a lot simpler than that, because:
- the HTTP/1.1 stack is written with a simple request/response API in 
mind, which simplifies it a lot
- the servlet API interfaces implementation are isolated from it

The Coyote "framework" is just a very simple API, is made of two main 
objects (request/response), the messaging objects and two interfaces. It 
seems like it is much simpler to write a connector for it rather that it 
is to write a connector for Catalina directly.

Of course, if you try to write a really optimized connector, like the 
Coyote HTTP/1.1 connector, then I suppose it gets more complex.

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Proposal draft for Tomcat 5.0 : #2 Tradeoffs

[co...@covalent.net]

On Fri, 21 Jun 2002, Christopher K.  St.  John wrote:

>  People are +1'ing the _goals_ of the proposal, but I
> the proposal itself doesn't give sufficient detail to
> determine if the recommended actions will actually 
> lead to those goals being accomplished.

That's exactly the target - to set the goals and the overal
direction ( it's a 'long-term plan' ). Each particular
detail will be discussed and revisited many times during the 
implementation stage. 


>  Some of the goals even appear to be contradictory,
> but there's no discussion of the inevitable engineering
> tradeoffs. Simplicity vs Flexibility is a big issue.

The goal seems to be to get more flexibility and a simpler
core. I seen no contradiction here - our experience so far
seems to indicate that by reducing complexity you gain
more flexibility.


>  For example, the Coyote framework is compatible with
> Tomcat 3 and Tomcat 4. This is admirable, and may lead
> to closer ties between the two groups of developers.

>  BUT Coyote is also more complicated and harder to
> understand than the HTTP connector code in Tomcat 4 that
> it replaces. It does more, too, but let's face it, it's
> an integrated framework for writing connectors, and
> frameworks are harder to understand and build than
> single-purpose code.

Coyote is not a framework for writing connectors - it defines
the base objects and a hook mechanism. 

It is not perfect - and one of the goals is to improve it
in tomcat5. But most of the stuff is needed to get decent
performance - and to be able to support other protocols
and have better integration with the server.

There are many things that are hard or impossible with o.a.ajp.

>  That isn't to say it wasn't worth it, but you've gone
> from only needing to understand o.a.c.connector to having
> to understand a whole slew of packages and patterns and
> conventions. There's more buy-in required.

????

What do you mean 'only o.a.c.connector' ? There are few dozens
interfaces and classes you must understand, and the point is
you can't get too much performance without good buffer management,
byte[], optimized conversions, etc. 

Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>