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
- Re: HttpClient integration Ryan Hoegg
- Re: HttpClient integration Andrew Evers
- Re: HttpClient integration Ryan Hoegg
- Re: HttpClient integration Andrew Evers
- Re: HttpClient integration Ryan Hoegg
- Re: HttpClient integration Ryan Hoegg
- Re: HttpClient integration Andrew Evers
- HttpClient integration Sven Ludwig