> Myself and another coder here are looking to implement some secure > xml-rpc clients and services, but it looks like the current code base > is very much in flux with the recent refactoring/addition of the > XmlRpcTransport stuff. My question to the list is should we take a > crack at implementing SecureXmlRpcTransport or does someone have > something in the works already?
Well, I'm responsible for that particular refactoring, as far as I know noone is working on the area you mention, so by all means have a go. I think there were a couple of posts with proposed changes to the secure behaviour on this list about 2 weeks ago. If you want to start work on a SecureXmlRpcTransport and post the extra classes to the list, then I can review them and commit them (unless there are major objections). Alternatively, create a ticket in bugzilla and attach them to that: http://nagoya.apache.org/bugzilla/enter_bug.cgi > We are assuming that the secure.SecureXmlRpcClient will be depreciated > by XmlRpcClient using a transport factory that looks at the URL > protocol to decide whether to do DefaultXmlRpcClient or > SecureXmlRpcTransport (or something else), are we off the mark? Probably ;), in that I haven't really thought that far ahead. If you develop a secure.SecureXmlRpcTransport with constructors: + URL (obvious, but check for https://), + String (as URL but for convenience) and, + Hashtable/Properties (think client certs and the like). Then we can plug this into whatever generic mechanism we use for transport creation, and leave things open enough to allow programmers to instatiate a custom transport or extend the transport to develop their own. Andrew.
