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


Mime
View raw message