some corrections

[Sylwester Lachiewicz <mx...@plusnet.pl>]

Hi,
1. i found that url to cvs repository was changed - new is for web: http://cvs.apache.org/viewcvs/ws-xmlrpc/
cvs project name: ws-xmlrpc - project.xml needs update.

2. project version in sources is 1.2-a3-dev byt in project.xml was 2.0-a1-dev

3. updated to last vesions: httpclient 2.0-rc1, commons-logging 1.0.3, junit 3.8.1 jsse 1.0.3_02 - removed dependency from fesi

and question: which xml-apis version is required? is possible to remove classes from org.sax and use standard api jars ?

Sylwester

Compressing requests/results...

[Michael Landon - IBN <ml...@ibnads.com>]

We've been using xml-rpc for about a year now & are very impressed with its capabilities.  A problem, however, has been the increased bandwidth requirements when sending xml streams (as opposed to binary object streams).  The good thing, though, is that these xml streams are perfect candidates for compression.  So, if I could make a small request, maybe the XmlRpcClientLite & WebServer objects could incorporate the use of

    Accept-Encoding: gzip
and
    Content-Encoding: gzip

headers.  Here's how I could see it functioning:

  The client's request would include the "Accept-Encoding: gzip" header.  The server would always look for that header...and if found, the server would encode the response w/ the built in Java GZIPOutputStream object and then include the "Content-Encoding: gzip" header w/ the results.

  Alternatively, if the incoming client's request included the "Content-Encoding: gzip" header, the server would decode the request w/ the built in Java GZIPInputStream object & respond as above.

  If neither header is not found, the server responds as normal (no compression), but includes the "Accept-Encoding: gzip" header w/ its results.  

  Back on the client side, if the client receives results w/ the "Content-Encoding: gzip" header, it would decode the results w/ the built in GZIPInputStream object.  From that point on, the client would always send compressed requests (including the "Content-Encoding: gzip" header).

  If the client receives the "Accept-Encoding" header from the server, the client would process the results as normal (no decompression) but from that point on would compress all requests.

I think this method would allow for full backward compatibility w/ older versions of xmlrpc and not break any spec rules.  It just seems like such a simple enhancement with many benefits.  Thoughts?

Michael