Re: Beta: Bug, Wishes and Suggestions

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

Hi Christoph,

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

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

Christoph Theis wrote:

>Hello!
>
>I'm using the beta (downloaded it a few days ago) and I have some
>questions and suggestions:
>
>1, the bug. In XmlRpcClient.java, about line 290, you have the following
>statements:
>
>while (call != null)
>{
>  call = dequeue();
>  executeAsync(call.request, call.callback, call.transport);
>}
>
>This throws a NullPointerException. I think the code must be as
>follows (dequeue and executeAsync exchanged):
>
>while (call != null)
>{
>  executeAsync(call.request, call.callback, call.transport);
>  call = dequeue();
>}
>  
>
Sounds like a bug report.  If you don't mind, please post it at 
http://nagoya.apache.org and include a TestCase

>2, the wish: Can you make the class ServerInputStream public? I want
>(or I have to) implement my own transport class, derived from
>LiteXmlRpcTransport, and I would like to use this class as well.
>
+1, I see no reason not to.  FYI, that's the reason we abstracted the 
Transport stuff :)

>3, the suggestions: The reason for 2: In LiteXmlRpcTransport, you are
>creating a BufferedOutputStream with the default size of 512 bytes.
>That's pretty small, event the TCP layer can handle about 3 times this
>size. The disadvantage of this small buffersize is: When the call is
>larger than those 512 Bytes, first the header will be written and then
>the remaining data. But the sockets are blocking, so writing the
>header you will have to wait for the ACK from the server. But the
>server (or the underlying TCP stack) will wait for more data and only
>after a timeout (about 100ms or more) will send the ACK. The total
>cost of my call is about a few ms, but most of the time I had to wait
>for the ACK from the server! This is a significant performance hit!
>With the Beta you have a better class design, making it easier to
>overload and work around this buffer problem. But perhaps you could
>provide a way to set the buffer size from extern, or try to send the
>request in one call, making the buffer the size of the request plus
>header.
>
I could be convinced this should be changed in all three 
XmlRpcTransports.  +0, until I see a TestCase. :)

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

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Re: Beta: Bug, Wishes and Suggestions

[Andrew Evers <an...@redwood.com>]

> Short answer: I can see making a distribution that does not depend on 
> HttpClient.  I can't see making one that doesn't include Base64 (from 
> the Commons Codec package).
> 
> Long answer:
> HttpClient is definitely a "nice-to-have" for doing stuff that is 
> outside the strict XML-RPC spec.  Therefore, I am up for making a 
> separate module for that transport.

I agree with this, as long as it can be excluded from a minimal
distribution.

> Base64, on the other hand, is an official XML-RPC data type, added to 
> the spec [1] in January 1999.  I would vote -1 on distributing something 
> where it wasn't built in.  Feel free to remove it from your local fork 
> though. :)

I think we do need to be very careful about dependencies, even 
on the commons project. While it is great to be able to re-use 
code (particularly in the case of the HttpClient), we then need 
to manage these dependencies safely.

The application I have embeds XML-RPC and may be embedded in
larger web applications, and I am certainally not the only one
doing this. As XML-RPC is embedded in more applications the 
potential for dependency problems increases.

I think we should distribute several jar files:

1. An absolute bare minimum client for use in applets.
2. A more fully featured client that can be configured to use
   external libraries.
3. A client and server that can be configured to use external
   libraries.
4. A standard 3rdparty jar that contains repackaged commons
   code to make the library easy to embed.

Users can then make trade offs between size and features. The
standard 3rdparty jar means that they don't need to go somewhere
else to get the Apache Commons Codec, HttpClient, SSL? etc. But,
they still have a simple deployment option if they want to use the
full versions of this software (or only part of it). I don't think
that we should require developers to repack jar files from us in
the majority of circumstances.
 
However, I do find the dependency on the Commons codec more 
worrisome. While it is great that someone else has written the
code for us (and has hopefully dealt with a lot of the interop), 
I don't think that their codec is particularly well suited to 
applet deployment: we end up importing a lot of interfaces 
that don't provide us with any clear functionality. The 
compressed commons-codec.jar from the current release is 
about 12k, which is a reasonable percentage of our current 
applet code base, our own Base64 codec uncompressed is a
fraction of this size. I think it would be safer to continue
to distribute our own Base64 codec and fix the remaining
issues.

Having reviewed the codec, I'm not sure that its whitespace
handling (always an issue with our codec) is any superior to
ours. It doesn't seem to generate whitespace when it might be
recommended, and doesn't seem to be able to consume it either.
I think we may be throwing the baby out with the bathwater on
this one, I'd be happier fixing bugs in our current codec than
importing the codec from commons (and when I say I, I mean
me).

Andrew.

Re: Beta: Bug, Wishes and Suggestions

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

Christoph Theis wrote:

>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
>
Short answer: I can see making a distribution that does not depend on 
HttpClient.  I can't see making one that doesn't include Base64 (from 
the Commons Codec package).

Long answer:
HttpClient is definitely a "nice-to-have" for doing stuff that is 
outside the strict XML-RPC spec.  Therefore, I am up for making a 
separate module for that transport.

Base64, on the other hand, is an official XML-RPC data type, added to 
the spec [1] in January 1999.  I would vote -1 on distributing something 
where it wasn't built in.  Feel free to remove it from your local fork 
though. :)

By the way, thanks for the bug reports!

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Re: Beta: Bug, Wishes and Suggestions

[Christoph Theis <th...@gmx.at>]

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

Re: Beta: Bug, Wishes and Suggestions

[Christoph Theis <th...@gmx.at>]

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