> 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: XmlRpc XmlRpcException XmlRpcClientRequestProcessor (see above) XmlRpcClientResponseProcessor (see above) HttpClient (I've factored this out of XmlRpcClientLite). Base64 ServerInputStream This would have no main(), no asynchronous handling, no workers or worker stack, etc. But, it would be _very_ small. Andrew.
