tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: Jk2 object model
Date Sun, 11 Jan 2004 01:35:43 GMT
Mladen Turk wrote:
>  
> 
> 
>>From: Henri Gomez
>>
>>
>>As many I feel that jk (and maybe also jk2) are now pretty 
>>stable, and I don't see the need for a new just web/tomcat connector.
>>
> 
> 
> Finally someone :-).
> 
> That's why I did try to use the revolutionary approach. Jet another
> connector wouldn't make a much difference (quite contrary thought).
> 
> If there is a need among community for slightly different-then-connector
> approach (I've used the term integrator, and IMO it would better describe
> that new concept), we should discuss that further.
> 
> But this time I'd like to spend a month or so doing 'real' design without
> the single line of code. If we manage to put and describe our needs on the
> paper, the coding itself will took insignificant amount of time. If this
> plan shows that 90% of the existing codebase can be reused; even better.


Good luck with that... I don't believe in "real design without a single 
line of code" - and I'm not quite sure about "putting the needs on 
paper" ( at least not in the sense you seem to mean it ).

One thing should be clear - existing needs must continue to work - for 
example even if a fancy new autoconfig is used, users should still have 
the ability to do manual configuration.

For example:
- support for apache1.3 and multiprocess servers -> deal with the 
limitations of the back-communication.
- ability to serve static pages with apache -> no mod_webapp "dumb 
server" approach

There are 2 major areas to discuss:
- low-level model - object model, extension points and request 
processing model

- various modules - to implement whatever protocol, to implement 
configuration, etc.

The first thing ( IMO ) is to decide on what improvements we need
on the lower layer so it can satisfy any additional needs you may have -
configuration, performance, integration with a wider set of 
applications, etc.


Costin





> 
> But once again, I don't wish to be limited by the existing codebase, that
> will limit the design from the start. If we manage to put ourselves in the
> neutral possition, we might do something.
> 
> 
> 
>>And we even a little more ambitious, we could think in term 
>>of Java to Native broker, not sure Tomcat to Native...
>>
> 
> 
> If we on the end decide that this new integrator isn't what we need (or we
> don't have enough resources to implement it), at least it will show some
> directions for the existing connectors to follow.
> 
> MT.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message