[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-general
Subject:    Re: ServletRequest - not HttpServletRequest
From:       Lucas Gonze <lucas () gonze ! com>
Date:       2000-04-24 21:54:40
[Download RAW message or body]

Thanks Andy.  This is very useful.

Andy Riedel wrote:
> 
> Lucas,
> 
> You may want to take a look at the Catalina classes that will make up the
> framework for Tomcat 4.0. They are being designed to support protocol
> independence. I agree with you that the base tomcat servlet engine supports
> many features that should not need to be rewrittenf ro each new protocol.
> 
> My desire is to support the SIP protocol with the Tomcat servlet engine. I
> wish to make sue of all of the base servlet support such as thread pooling,
> session management, etc but have the request/response protocol be SIP.
> 
> Catalina is being designed to solve the need for protocol independence. It
> allows you to easily plug in your own Connector objects to understand your
> protocol.
> 
> Andy
> 
> At 12:35 PM 4/24/00 -0700, Costin Manolache wrote:
> >Lucas Gonze wrote:
> >
> > > > My recomandation is to use an API that fits your protocol, and create
> > > > adapters if you want to use servlets to generate dynamic content for
> > > > your application. There are APIs for mail, IIOP, SNMP, etc - use the
> > > > right tool.
> > >
> > > The reason to use tomcat for non-http protocols is to take
> > > advantage of its many resources.  The support code for
> > > getresourceasstream, WAR files, the installer, etc. is all stuff
> > > I'd have to implement myself.
> > >
> > > As I mentioned, I have a little tcpserver that I subclass to make
> > > specialized servers.  This approach works well for experimental
> > > tools, but when it comes to adding polish I'd rather piggyback on
> > > other people's work.
> > >
> > > Also, the support code for servlets themselves is very handy.  I
> > > have now moved completely to tomcat from my http subclass of my
> > > tcp server, because the toolkit is so useful.  I'd like to not
> > > have to support both.
> >
> >You can use tomcat implementation ( ThreadPools,
> >XML stuff, deployment, etc).  The TCP part is HTTP-independent
> >and can be used in any server, the threading, etc. The only place
> >where Tomcat is HTTP specific is in the implementation of the
> >servlet API ( i.e. tomcat.core and the interceptors - are HTTP-specific).
> >Even in this case - the interceptor itself is supposed to be a
> >bridge between Servlets/HTTP world and various non-http APIs.
> >
> >
> >The only problem is if you want to use Request/Response as an API
> >to model your protocol. If your protocol is not stateless it will be even
> >worse.
> >
> >Most protocols I know already have a defined API. If it's a new
> >protocol - it's still better to define an API based
> >on your use of the protocol. If it's close enough to HTTP and
> >servlets - it's probably  a good idea to try to just use HTTP.
> >
> >Of course, this is just IMHO. I'm curious to understand
> >what protocols do you want to support and how far they are
> >from HTTP.
> >
> >Costin
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: general-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

-- 
L.U.C.A.S.: Lifeform Used for Calculation and Accurate Sabotage

[prev in list] [next in list] [prev in thread] [next in thread]