[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    Re: Beta: Bug, Wishes and Suggestions
From:       Christoph Theis <theis.news () gmx ! at>
Date:       2003-05-18 16:32:02
[Download RAW message or body]

Hi Ryan!

> I addressed each item inline.  Also, I CC'd the dev list, as all of this
> stuff seems to be relevant there.

OK, I wasn't sure if this belongs to the user or dev list.

> BTW, this all seems to be relevant to cvs HEAD, not the 1.2 beta.

Yes, you are right :)

>>4, a question: The former version were very small, a jar file of about
>>50kB. Now, I need the codecs (a large jar file) and probably the
>>httpclient (a huge jar file). I see the point of having just one code
>>to implement the Base64 encoding / decoding. I don't see the point of
>>having a multi-purpose-client, which can handle cookies, show frames,
>>enlarge my penis size, ... *ooops* ;) I don't know, if I can use the
>>xmlrpc jaf file without the codecs (I don't use Base64 at the moment)
>>and without the http client. I compiled the sources without servelet
>>and applet (removed it from the source) but I still need the codec.
>>But then, it's not your code anymore, and this is the problem! I would
>>like if you could split the code somehow, so one could use the small
>>xmlrpc client alone and add codec and especially the http client only
>>if needed, as an add-on.
>>  
>>
> I was the one who built in the HttpClient code.  It is only necessary 
> for building or using the the CommonsXmlRpcTransport.  On my TODO list 
> is to break up some of this stuff into modules, specifically for 
> situations like yours.  Any suggestions for logical modules?  For 
> instance, is your use case similar enough to the applet use case or 
> would we want two separate modules, an Applet module and a DietXmlRpc 
> module?

I have a Java application that has to communicate with an application
written in C++ running on Windows. The communication is very simple: I
keep one connection between the client and the server open, and the
client can send its requests and read the responses via this
connection. Thus, the server knows when the client exits and can free
some resources. I choosed xml-rpc because it was easy to implement on
the server side and offers all I need (and much more). Of all the data
types I only use numbers and strings, arrays and structs as well, but
not binary data. Also authorization is not a concern (at least at this
moment). My goal is to have a small client with a short download size,
that can be installed via WebInstall and run virtually anywhere.
Currently my class files sum up to about 200kB (I have to tweak a
little bit...), I guess a jar file would be half the size.
Because I don't use binary data I don't want to have the additional
download of the common-code jar. And because I have a very simple
communication without authorization I want to avoid the download of
the HttpClient. If I need Base64 I might think about writing my own
class, if this would be much smaller than the full-featured
common-codec. Similar for the HttpClient: If i need https,
authoriazation, multiple connections, I will think about using this
(nice to have it :), but as long as I need just a plain socket and
can write and parse the HTTP header myself, I want to avoid relying
on it. So I would like to see I can use the xmlrpc.jar without those
two additional jar, but have the ability to among them, if I need a
Codec or a client.


Kind regards

Christoph


[prev in list] [next in list] [prev in thread] [next in thread]