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
|