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 17:29:29 GMT

Andrew, I must not be making myself clear, and the blurry definition of a 
"context" object is confusing things.

My whole purpose of adding the ability to read and write headers, is so 
the client can _propagate contextual information to the server_ which are 
not part of the rpc arguments, and are potentially handled behind the 
scenes on the server side (or perhaps explicitly through a ContextHandler 
as you proposed).  The whole point is to propagate contextual information 
from the client to the server, so of course being able to set said 
information on the client is necessary.

Here is a simple example: perhaps I want to record, oh, the Operating 
System of each client.  The client then needs the ability to send the 
operating system as a contextual information to every call it makes, 
along side the call, behind the scenes.  Of course, the alternative is to 
sprinkle an extra parameter (or more) in every single call that could 
ever possibly be made.  The point of contextual information (at least how I 
am using it, and how I think it is used in most RPC terminology) is to pass 
along some meta-information alongside a call that is handled seperately 
(for instance it may be logged in a database on the server side 
regardles of what call was actually made).  Otherwise I can't find the idea 
of server-side-only contextual information very useful.  The ability to pass 
arbitrary contextual information is IMHO mandatory when you are 
integrating with disparate systems.


>> 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).
>The context itself is set by the XmlRpcServer's or XmlRpcWorker's
>caller. This might be WebServer, or a Servlet, the SecureWebServer,
>or a custom HTTP framework. The former two might just create a
>DefaultXmlRpcContext, but the latter two might pass in a different
>implementation that may provide extra information (SSL credentials,
>or a Session like interface). This extra information can be passed
>in with no framework changes, and no need to modify the XmlRpcRequest
>itself (or the XmlRpcRequestProcessor).
>There is no need to change the client at all. These patches allow
>server embedders to decode (or pull out of the air) extra information
>and pass it along with a request. Relatively standard information
>(like HTTP headers) should become part of the XmlRpcContext interface,
>extra information can be added by an implementation and handled
>using casting.
>If you were implementing a request chaining system, you may want to
>add information to the XmlRpcContext as it passes through the
>request chain. In this case the context information is changing, but
>the request itself is not modified.
>It would certainally be worth modifying the client so that it took
>an XmlRpcContext (although the getHandlerMapping() is irrelevant
>here and may be ignored) and encoded the standard information (like
>username, password, http headers) into the request.
>Since XML-RPC is already an RPC mechanism, complex context information
>should really be passed as parameters to the RPC's themselves. The
>XmlRpcContext provides a way to access server-related information,
>and connection details mainly useful for authentication.

View raw message