Re: ServletRequest - not HttpServletRequest

[Andy Riedel <an...@hearme.com>]

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

Re: ServletRequest - not HttpServletRequest

[Lucas Gonze <lu...@gonze.com>]

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