Re: Tomcat-Lite - part 1

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

On Sat, 2008-08-30 at 20:44 -0700, Costin Manolache wrote:
> > > - Valves/LifecycleListeners versus plain Filters and listeners
> >
> > Personally, I think the strong type barrier between userland and the
> > container is nice.
> >
> 
> Access to low-level container objects ( which is the 'barrier' you mention )
> has many
> benefits, there is no doubt that the new model won't fit all cases and can
> be slower.
> 
> But I think it's good to explore the 'lazy' choice as well - people can and
> do write all
> kind of filters for auth, custom session management, etc - and for many the
> lower
> barrier does matter. Making it easier to integrate those plain filters into
> the container
> has tons of benefits - some may be converted to Valves ( in 'regular'
> tomcat) if needed.

No problem with that.

> > I am interested to look at the code like the proxy, and see if what it
> > can do.

> Unfortunately SelectorThreadApr is not up-to-date, it shouldn't be hard but
> it's lower priority for me. You can get an idea from SelectorThreadNio.
> I didn't implement the POST side of the proxy yet

I did not look at it at all yet. Personally, I am interested in the
simple proxy scenario (where for some reason you want to send a request
to another HTTP server somewhere). Not doing POST means not doing the
hard part ;) Bad Costin ;)

> Sorry - the actual argument I'm planning to use is complexity and number of
> layers. Size is just an extra benefit of reducing the complexity, I think
> performance
> and maintainability will be other ( but I didn't benchmark yet, nor do I
> think this is the
> main issue ).
> 
> It also depends on the target hardware, but I agree - if you want JSP and
> lots of feature it's better to
> use the regular tomcat. What I'm using in most of my experiments (on arm
> 200..300 Mhz / jamvm / ~64M RAM )
> is plain coyote.

I just wanted to point out that "regular" Tomcat would not change much
in size, but I am obviously fine with you refactoring Tomcat.

Rémy



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