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 13:28:59 GMT

On Fri, 13 Sep 2002, Andrew Evers wrote:

> > As far as my original attempts to get the interceptors patch noticed,
> > you  can find some of the history here:
> > http://marc.theaimsgroup.com/?a=93724818900001&r=1&w=2
> I just looked over the patch, and it seems to me to be inverting things
> a little. An XmlRpcRequest is really a part of a larger outer request
> that has come in via HTTP. The HTTP request is really the context in
> which the XML-RPC occurs. It is also imaginable that an XML-RPC may
> not come in via HTTP (message-oriented-middleware anyone?).
> Putting HTTP specific information into the request is problematic
> because it violates layering (slightly), but it also means that
> everyone that embeds the XML-RPC package in a HTTP implementation
> needs to modify their code to support the new execute methods.

Well, nothing I have done is HTTP-specific per se.  The XmlRpcRequest 
mods I posted on Wednesday include a generic headers Properties object 
in the XmlRpcRequest object.  Currently, since HTTP is the *only* transport 
at this point (and in fact, it looks like the spec binds XML-RPC to HTTP, if 
I'm reading it right), those are the "headers" which are populated.  But 
there is nothing to say that whatever is responsible for the transport 
layer, cannot write the "headers" and populate the headers on the server 
side in whatever fashion it chooses.  For instance, if for some reason there 
was an SMTP transport, I'd imagine SMTP headers could be written to the 
headers object, including custom application headers.  This is the same 
way 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.

> 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.

> An alternative method that should require less modification to the core
> XML-RPC code is to pass around a context object (either an Object, or
> a _very basic_ XmlRpcContext interface) passed in to the execute(*)
> methods in XmlRpcServer and XmlRpcWorker. The current execute(*)
> methods would call the new methods with context = null.
> Then, add a factory method in XmlRpcServer to create XmlRpcWorker
> instances:
> protected XmlRpcWorker createWorker()
> {
>   return new XmlRpcWorker(handlerMapping)
> }
> - return new XmlRpcWorker(handlerMapping);
> + return createWorker();
> Now, you can subclass WebServer, XmlRpcServer and XmlRpcWorker to
> create a framework with all the filtering you like. There is no
> interface (or performance) impact for people not needing the
> extra features, but they are available if required. You can now
> pass around arbitrary context information (maybe SSL connection
> information) for use by the worker, with minimum impact to
> the rest of the framework.
> You can even pass the context object right into the handling
> object if you create extended versions of the XmlRpc<X>Handler
> interfaces, or a parallel XmlRpcContextHandler interface with
> a setContext() method.
> Andrew.

If you are proposing a pluggable transport and worker classes that's 
fine by me.  The mods I made don't really effect the functionality of the 
code in XmlRpcWorker, it just adds header accumulation and in the 
case of interceptors some extra callbacks.  I suppose I could extend and 
override XmlRpcWorker if there was a way to plug my implementation in 
XmlRpcServer (getWorker()).

Just to be clear, is there something specific about my patch Wednesday 
("more refactoring with XmlRpcRequest") besides the deprecation of the 
execute(<params>) calls in favor of execute(XmlRpcRequest).  Note, I /did 
not/ force XmlRpcHandler to use XmlRpcRequest...invoker still invokes as 
execute(methodName, params) and I have no intention of changing this 
(although if developers want access to this on the server side, we might 
want to provide some mechanism for getting the XmlRpcRequest).  For my 
Wednesday patch, the developer API is not even changed besides the 
deprecation of the XmlRpcServer execute(<params>), which can be easily 
be un-deprecated to assuage fears.  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.  It may just be a 
matter of opinion.  I'm not tied to Wednesday's patch, I just thought it 
was a decent next step in refactoring.


View raw message