Had a look over the current snapshot of where you are. I like the ideas there, although I believe the authentication information may not belong in the base XmlRpcContext as there are probably people who want to do authentication "in band" instead of "out of band". I believe more discussion is needed here. Ditto for setBasicAuthentication being in XmlRpcClient instead of an implementation of XmlRpcTransport.

From an architectural standpoint, the implementation of the ideas in XmlRpcClientLite as a LiteXmlRpcTransport got me thinking. Why not strip down the base package to the bare essentials i.e. XmlRpc, XmlRpcRequest, XmlRpcResponse, TypeFactory, and whatever else we need no matter how we want to use the library. Now the base package is "lite" by default. We can then create packages for the different implementations, such as org.apache.xmlrpc.clients.liteclient, org.apache.xmlrpc.clients.commonsclient, org.apache.xmlrpc.clients.defaultclient, andrew.evers.xmlrpc.persistenthttp, org.apache.xmlrpc.server.defaultserver, etc.

This gives the ability to create separate JARs for each implementation and streamlines the redistribution of this package in other products (say Turbine wanted to ship an XML-RPC client as a part of their RSS stuff, but they already use the commons HttpClient for other things).

Thoughts?

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Reply via email to