Re: SecureXmlRpcTransport?

[Ryan Hoegg]

I am also involved in this refactoring and I think your contribution would be appreciated. Specifically, it could fill a need for a lightweight SSL transport to go with the lightweight cleartext transport. The Jakarta Commons HttpClient transparently handles SSL, and I will contribute a transport based on that PSN. ;) Some end of year projects have taken me out of circulation for the past few weeks.

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

Andrew Evers wrote:

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.