> 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.
Well, the XmlRpcContext on the server side is meant to encapsulate information that is not part of the XML-RPC request itself. This especially any HTTP or higher layer information. Since Basic/Digest and Cookie based auth schemes use HTTP headers, I decided to put the information into the context object. If you are doing authentication in-band (part of the XML-RPC parameters), then you probably wouldn't be using the AuthenticatedXmlRpcHandleranyway, and the information in XmlRpcContext is of little use to you. If you are doing authentication out-of-band (part of the HTTP request, SSL layer or even by IP address) then the XmlRpcContext is where that information should come from. The context information is passed in in parallel with the request to XmlRpcServer.execute(InputStream, XmlRpcContext) To complete the refactoring I want to move the parsing of headers into a method in WebServer that returns an XmlRpcContext. This can then be overridden to implement different schemes for header based authentication parse the headers. This would be the similar to the role of the transport classes on the client side, but the other way around. At minimum the XmlRpcContext needs methods to get the method (assumed to be POST), URI and HTTP version, and the HTTP headers. I would also like to add methods to allow authentication to be done by SSL client certificates. > Ditto for setBasicAuthentication > being in XmlRpcClient instead of an implementation of XmlRpcTransport. The only reason I left it in XmlRpcClient was for backward compatibility. I agree that it should be in the transport. This would actually make the transport classes look a lot cleaner too ;) > 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. I like it. We can then also reduce the footprint for people using the XML-RPC client in an applet. The client could potentially only be 8 or 10 classes from org.apache.xmlrpc. This has an added benefit that only the classes in the core package need to be Java 1.1 compliant, we are free to build implementations that depend on 1.2+ features in the extension packages. The only thing we need to be careful of is dependencies between these packages. If they get out of hand, then you end up having to pull the whole thing along anyway. A rule I tend to use is that a sub-package may depend on a super-package, but never the other way. Sub-packages may depend on outside packages. Andrew.
