HttpClient integration

[Daniel Rall <dl...@finemaltcoding.com>]

Daniel Rall wrote:

>Okay.  I'm really into using Jakarta Commons HttpClient, but worry
>about how use of it will affect applets (it's yet another JAR to
>download).  Unfortunately I haven't had time to keep up on your work
>-- is there any way that we could have two clients, one which uses
>HttpClient and one which uses the existing code?  I'm imagining
>something like the following:
>
>                       XML-RPC client interface
>                           _.        ._
>                           /|        |\
>                          /            \
>                         /              \
>         Impl using HttpClient    Impl using home grown code
>
>That way those who didn't want to have to distribute the HttpClient
>JAR for their clients could still use the clunky old code.  Right now
>we have two (non-SSL) clients, but they don't seem to do much
>differently.
>  
>
Feel free to take this on-list if you think appropriate.

I think the distinction you make above sounds a lot like turning 
XmlRpcClient and XmlRpcClientLite into two implementations of an 
interface.  If that's the case, I think XmlRpcClient should become an 
interface and we can rename XmlRpcClient to XmlRpcClientHeavyImpl or 
something like that.  I'd be happy to help but I may not be the best one 
to determine what goes into the interface and what stays on the class... 
for instance, does the setBasicAuthentication become an interface or 
does it live only on the HeavyImpl?

Also, any talk about XmlRpcClientLite should probably include John 
Wilson as he seems to be the committer behind the lightweight code.

--
Ryan Hoegg
ISIS Networks





-- 

Daniel Rall <dl...@finemaltcoding.com>

Re: HttpClient integration

[Ryan Hoegg <rh...@isisnetworks.net>]

I've been thinking further about this issue.

If we decide to go ahead and make an XmlRpcClient interface, we either 
have to decide to use some NonImplementedException framework for the 
features of the interface that XmlRpcClientLiteImpl does not implement, 
or we need to use an abstract class with the bare minimum for the root 
interface and inherit XmlRpcClientWithMoreHttpFeatures from it.

Are there other features XmlRpcClient provides now that XmlRpcClientLite 
does not, like multithreading?  If so, these should be addressed as well.

Thoughts?

--
Ryan Hoegg
ISIS Networks

Re: HttpClient integration

[Ryan Hoegg <rh...@isisnetworks.net>]

I've been thinking further about this issue.

If we decide to go ahead and make an XmlRpcClient interface, we either 
have to decide to use some NonImplementedException framework for the 
features of the interface that XmlRpcClientLiteImpl does not implement, 
or we need to use an abstract class with the bare minimum for the root 
interface and inherit XmlRpcClientWithMoreHttpFeatures from it.

Are there other features XmlRpcClient provides now that XmlRpcClientLite 
does not, like multithreading?  If so, these should be addressed as well.

Thoughts?

--
Ryan Hoegg
ISIS Networks