xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Evers" <aev...@redwood.nl>
Subject Re: XmlRpcClient Interface
Date Mon, 04 Nov 2002 16:10:59 GMT
> I have the CLDC code, but didn't find the interface.  Is it hidden in
> CVS or elsewhere?  Also I modified the XmlRpcClientLite, my
> recollection is that there are plans for this that will modify it
> significantly.

Ryan and I are sharing code via private email at the moment.

> This is the gist of the modifications.  I removed the superclass
> (XmlRpcClient) and copied a couple of methods across and removed the
> superclass of LiteWorker (Worker) and copied some methods.  I think
> that I also trashed the Async code. There are minor changes to
> XmlRpc.java (removing "properties"), other than that, you need
> Base64.java, ServerInputStream.java and XmlRpcException.java which
> compile unchanged.  I think that there also some supporting classes
> that we had already created (StringTokenizer?), maybe others.
> References to URL and associated exceptions have been removed, if we
> need these to match a new interface (likely) we will need to create
> substitutes.
> If anyone else has an immediate interest in this code, let me know.
> I'll be testing over this week, the goal is to get it on the
> iPaq/Jeode.

I wouldn't mind seeing a copy (either a unidiff against HEAD or a
..jar of .java files). I can tell you fairly quickly how easy it would
be to integrate this.

I've not done any CLDC programming myself. What are the constraints we
are looking at? How important is code size, and the number of classes?
are there particular classes that we are using that aren't available
under CLDC?

>>> I only vaguely remember the discussion of adding an interface for
>>> the client.  Can someone provide a quick synopsis and the status?

Well, the idea is to split the XML-RPC and HTTP processing. The
XML-RPC processing on the client side will be done in a similar
manner to the server side code in HEAD. There are three new classes:
XmlRpcClientRequestProcessor, XmlRpcClientResponseProcessor and
XmlRpcClientWorker. These contain the request/response/worker
code that was common to XmlRpcClient and XmlRpcClientLite. Look how
this is done on the server for an idea.

The HTTP processing is handled by having XmlRpcClient make a call
to an XmlRpcTransport instance:

  public InputStream sendXmlRpc(byte [] request)
  throws IOException, XmlRpcClientException;

Creation of these instances is via a factory method in XmlRpcClient:

  protected XmlRpcTransport createTransport()

The default is to create a new transport (== new connection) for
each XML-RPC. It is possible to set things up to do XML-RPC on
a persistent connection.

>>> It just became relevent to me because I have a need for a CLDC
>>> client.  kxmlrpc assumes MIDP (HttpConnection).  Since MinML is
>>> (just about) CLDC compliant, if I can easily convert the
>>> XmlRpcClient to CLDC I may have a good solution. If I'm going to do
>>> this, I might as well make it compliant with the forthcoming
>>> interface.

The solution may be to create an org.apache.xmlrpc.cldc.CLDCXmlRpcClient
class that depends on the MinML package, and a subset of the core
org.apache.xmlrpc package:

XmlRpcClientRequestProcessor  (see above)
XmlRpcClientResponseProcessor (see above)
HttpClient (I've factored this out of XmlRpcClientLite).

This would have no main(), no asynchronous handling, no workers or
worker stack, etc. But, it would be _very_ small.


View raw message