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 Thu, 12 Sep 2002 01:09:59 GMT

I sent an email today describing a small patch which simply does 
a bit more refactoring with the XmlRpcRequest object, deprecating the 
various execute() methods that were around to use this central object.  I 
also added a few more fields to it, and the accumulation of headers 
(which aren't used at the moment).  This patch should hopefully be very 
straightforward.  I haven't written any extra test cases, but 'ant test' 
passes the test cases.  My intention is to hopefully build on this with 
an introspection patch and/or interceptors patch.  A Kevin Hester seems 
to have already contributed a patch implementing the exact same 
introspection I would (it all derives from the same original patch).  My 
introspection mods are sitting on my disk at work, I wanted to take one 
step at a time.  However it seems that maybe people don't want 
introspection in (for security reasons), which is fine.  Already (again) 
I hear someone asking about adding the ability to modify HTTP headers.  I 
hate to beat the same drum over again, but I have frequently replied 
to posts saying that the interceptors patch would handle this, not to 
much avail.  With the patch I sent today, at least this is a possibility 
without interceptors (because now XmlRpcRequest holds the headers).

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 

(it doesn't go all the way back because I started back when Hannes 
Wolfner was still running the project from his site)

To defend myself, I did describe what files were touched, what the patch 
did, and supplied a web page with further documentation on the flow of 
control, etc (it's all still there at: 
http://aeolus.cit.cornell.edu/xmlrpc/xmlrpc.html).  I also included a 
verbosely documented fully working example usage 
(http://aeolus.cit.cornell.edu/xmlrpc/InterceptorsSample.java.html).  I'm 
not sure if this counts as a "test case"...it is not a JUnit test case 
although it could encapsulated by one.  This was an update to a 
preexisting patch of mine, and I don't remember any feedback indicating I 
should provide any further test case.

I don't mind my patch being rejected, as long as I am at least told as 
much.  It is just frustrating to see people ask for the same 
functionality over and over again which could be provided by a patch 
sitting on my hard drive.

Personally, I don't see a critical need for introspection, however to do 
anything but basic HTTP authentication (and perhaps SSL, I've never tried 
that with this package), some sort of hooking mechanism is critical.  
CORBA has it, Tomcat has it, JBoss has it, even Axis appears to have it 
to some extent.  The overhead of XML parsing/generating, and network IO 
probably dwarves any other aspect of the library.

I think we are going to have to move to SOAP here (which is why I am 
investigating hooking mechanisms in Axis) because that is the train the 
industry has jumped on, so if the Apache xml-rpc community really doesn't 
want interceptors I'm not going to force it.

Aaron Hamid


Mime
View raw message