xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Evers" <aev...@redwood.nl>
Subject Re: recent patches
Date Fri, 13 Sep 2002 14:11:27 GMT
> [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()

I don't really even like the username/password being in XmlRpcRequest,
since they are external to the actual request itself, authentication
should really be orthogonal to the request handler itself.

>> There are a number of people embedding the XmlRpcServer without using
>> the WebServer. The recent patch I made makes it possible to embed
>> XML-RPC into an arbitrary HTTP implementation that already handles
>> threads (eg. a servlet engine, or a different lightweight HTTP
>> implementation).
> Is this patch committed?  Or can you point me to it.  I probably won't
> get a good idea of what you are saying unless I see the code.

Not yet, but imagine the guts of the XmlRpcWorker put inside a servlet
(since the servlet engine will handle threading), with an init method
that uses the ServletConfig to build an XmlRpcHandlerMapping. Basically
a hybrid between XmlRpcProxyServlet.doPost() and XmlRpcWorker.execute().

As far as using the XML-RPC framework within another HTTP framework,
the company I work for is doing this right now. We use the
XmlRpc{Request,Response}Processor classes directly, and skip the
WebServer/XmlRpcServer/XmlRpcWorker/*XmlRpcHandler classes entirely.

>> An alternative method that should require less modification to the
>> [snip]
> I think it is nicer to put a bit more
> data in XmlRpcRequest (including headers), and handle that class solely,
> instead of the various types of execute() calls we have internally.  It
> also allows us to extend functionality without adding extra parameters to
> calls, since we can just add it to XmlRpcRequest.

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.

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.


View raw message