xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ar...@cornell.edu
Subject Re: recent patches
Date Fri, 13 Sep 2002 15:04:36 GMT

comments embedded

> Date: Fri, 13 Sep 2002 16:11:27 +0200 (CEST)
> To: <rpc-dev@xml.apache.org>
> From: "Andrew Evers" <aevers@redwood.nl>
> Subject: Re: recent patches
> Message-ID: <63635.213.53.223.162.1031926287.squirrel@webmail.redwood.nl>
> 
> > [snip]
> > the Servlet spec works: you have a generic ServletRequest and
> > ServletResponse (at this time I don't think we need an XmlRpcResponse),
> >  and all handling revolves around them.
> 
> Indeed, but within the ServletRequest you have methods to access fields
> in the request and headers, and a method that gives you the inputstream
> for the remainder of the request after the headers. The way I think
> about it is:
> XmlRpcContext <-> ServletRequest.getXXX()
> XmlRpcRequest <-> ServletRequest.getInputStream()

Hmm, I wasn't making a distinction there, though I did add the inputstream 
to the XmlRpCRequest and added setters/getters for it.

[snip]
> This is the same idea I had with adding an XmlRpcContext interface, so
> that extra context information can be passed about. As long as the
> context class implements XmlRpcContext, it can implement additional
> interfaces that XmlRpcWorker descendants (or external WebServers)
> can pass information through. This information is kept separate
> from the XML-RPC request itself.

It doesn't really matter to me whether these are in the same object or 
not...their lifespans are identical.  I was mainly concerned about 
aggregating various arguments into one object representing the entire 
call.

> I had a go at implementing this, my next post contains a patch and
> explanation. This only effects the server side of things, it uses
> an XmlRpcContext object to encapsulate the state from the outer
> protocol (HTTP) and simplifies the content of the XmlRpcRequest.
>
> Andrew.

I see...presumably a subsequent patch which adds code to actually set 
the context on the client side will be forthcoming?  Then if the server 
side handler is a ContextHandler, it will be called with the extra context 
param, if I am understanding correctly?  I assume this context will be 
passed in some sort of HTTP header...perhaps serialized or something (if you 
really want to support arbitrary Objects).

Aaron

Mime
View raw message