xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <rho...@isisnetworks.net>
Subject Re: SecureXmlRpcTransport?
Date Thu, 19 Dec 2002 05:24:17 GMT
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

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:
>>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.

View raw message