The concept is really not that difficult. This patch simply adds the
ability to add callbacks ("interceptors", filters", "hooks", call
them whatever you want, "listeners" maybe?) which are called at specific
stages in the remote procedure call process. These interceptors are given
the contextual information of the call at the time (the operation name, the
method arguments, etc.), and are able to modify them when a
request/response is sent out over the wire, and conversely when a
request/response is read from the wire.
This is useful if you want to manipulate the call for instance, to add
some custom contextual information (e.g. security tokens), or if you want
to perform some operation on the generated XML document (e.g. encryption,
XSLT transformation, whatever). Since the XML-RPC library, as it is,
provides none of these hooks, I had to add them in. IMO, an "interceptor"
mechanism should be a standard feature of a remote procedure call
protocol. The only overhead this patch adds is accumulation of
HTTP headers (as far as I can tell there are only about 4 or 5 that get
sent), and iteration through the list of interceptors, which is simply a
no-op if none are registered. Performance can be further improved by
using nonsychronized list implementations, but I do not do this simply
for the sake of backwards compatibility with 1.1. (in any case, any
overhead this patch adds is dwarfed by the overhead of XML document
generation, parsing and transmission in the first place, so I think it is
a non-issue)
You'll have to refer to the XML-RPC Introspection site for details on
what that is. Basically introspection allows you to query the API
of the remote server, and get a list of calls, and a textual description
of those calls. Again, pretty straightforward stuff.
Look through and run the example (it should run "out of the box") and you
should get the idea. In the example I modify the arguments being passed,
add a custom header, and perform XOR "encryption".
Sure, some people will say PKI/SSL is the solution to the problem of
passing authentication information, and encrypting the stream...but not
everybody lives in the world of PKI yet - there are many other security
schemes and uses for manipulation of the rpc call (just off the top of my
head: on-the-fly GZIP compression of the request; XSLT transformations of
the XML-RPC document, to SOAP perhaps; dynamically translating from one
API to another, or between versions of APIs; logging each RPC call to
some logging service; sending out events based on RPC calls; on and on).
Also, please CC: my email address on responses - I have subscribed to
theh rpc-dev-digest list, but so far it seems to be a black hole out of
which I get no responses.
Aaron Hamid
> Begin forwarded message:
>
> > From: "EXT-Raiteri, Ashley L" <[EMAIL PROTECTED]>
> > Date: Thu Mar 07, 2002 08:33:59 AM US/Mountain
> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > Subject: RE: Interceptors/Introspection patch
> > Reply-To: [EMAIL PROTECTED]
> >
> > Aaron.
> > I am not sure I even understand what the patch provides.
> > The description in on your web page perhaps requires more knowledge than
> > I have to understand. Can you explain it more thoroughly.
> > Ashley Raiteri
> > Boeing S&C
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 06, 2002 1:40 PM
> > To: [EMAIL PROTECTED]
> > Subject: Interceptors/Introspection patch
> >
> >
> >
> > Guys, it seems like a new release went out today...I haven't been able
> > to
> > get a straight answer on whether any of you are interested in my
> > interceptors patch (since merged with Eric Kidd's Introspection patch).
> >
> > http://aeolus.cit.cornell.edu/xmlrpc.html
> >
> > Now that there is a new release I have to go back and update the patch.
> > Do you guys see any promise in this patch (either of them really)? The
> > less I have to maintain in parallel the easier my life will be.
> >
> > Aaron Hamid
> > Integration & Delivery
> > Cornell University
> >
> >
