Hi,

I'm still working on lite - right now my primary goal is to finish the
connector, and have it usable as part of tomcat7, along with
nio and apr connectors. The lite connector is based on nio ( could support
apr as well ), but is intended to be directly usable by
users - it supports both client and server modes, and instead of coyote it
has an API that is very similar with the servlet API - i.e
all methods plus setters for use in client mode.

I gave up on implementing the 3.0 servlet spec - tomcat-lite will only
support running a subset of the servlet API,
for anything else ( and to pass the TCK ) will use the full tomcat. The
'servlet' part will just be a small wrapper on top of the
connector - I don't want the connector to depend on the servlet API , so it
can be used as a http client without requiring the
servlet jars, and to avoid any compatibility requirements.

As features of the connector:
- the low level layer is refactored: instead of a growing ByteBuffer for IO
it uses a list of buffers ( avoids copy ), uses NIO for
charset conversions instead of the former hack, etc. It is also much closer
to apache2 bucket brigades.
- instead of coyote, it uses an API that is based on servlet, with the
addition of the missing getter/setter or pair APIs,
    for example Request.setParameter(), Response.getInputStream(), etc. The
idea is to allow people to easily
  port servlets, and to use a familiar API in client mode
- it is possible to write handlers that run in the IO thread ( like the http
proxy )
- while most of the code is originally copied from the existing connectors,
a lot has been changed to make it easier to
test and use ( or so I hope ).

I also added a SPDY implementation - this is a binary protocol, similar with
JK - it is supported by chrome browser ( with some flags ).
My goal was to try out the low-level layer - and to evaluate the protocol.
We keep discussion JK replacements - this is one option, and
I guess having the code to try it out wouldn't hurt. The nice thing about
SPDY (compared with JK and http ) is that it's multiplexing
requests - while JK and http are blocking, one TCP connection can't be used
for multiple forwarded http requests. There is also
a header compression option - I haven't done any load tests to see how much
it hurts/helps.

On the help part - obviously review and testing are the biggest needs.
Assuming people are comfortable with a 4th connector - there are
a lot of options that need to be ported, the code currently supports only
the basic requests. Still missing ( and in need of help ):
- compression ( I'm getting close )
- connection management ( working on it )
- sorting out the options in nio/apr and implement them
- make sure all servlet methods work in reverse ( for example
HttpRequest.setParameter(), HttpResponse.getInputStream(), etc ).

Also, I would like to know if other comitters are OK with (temporarily -
i.e. until the 7.0 release vote) including lite in the tomcat7 builds,
so people can try it out. I would like to have it in common/, so it is
visible in servlets - as I mentioned one of the goals is for tomcat-lite
to be more of a library that is used for client http, include
filters/servlets that can be used in any container, etc. When 7.0 is ready
we can
remove it or include it if you feel it's ready.


Costin

Reply via email to