Hi All, I agree with Jochen. There are a number of applications that depend on the current Java API. Furthermore, there is an established history of rejecting patches to add support for the Collections framework, as a number of users use XML-RPC from applets, and only have access to Java 1.1. I myself have rejected several such patches.
Reading this list, there appear to be two opinions of the direction that Apache XML-RPC should take. Traditionally the decisions made have been quite conservative: continuing support for Java 1.1, few changes that break the official specification, using a lot of our own (HTTP, Base64) rather than the Apache commons code. One of the strengths of Apache XML-RPC is its simplicity, not just in the XML-RPC wire representation, but also in the effort required to compile and use it. With XML-RPC 1.1 this basically meant you had a Java Virtual Machine 1.1 or later, the rest: SAX, HTTP and Object <-> XML transformation was provided by one small JAR file. Another group is using XML-RPC in more demanding applications where SSL, gzip encoding, HTTP proxies and the like are all requirements. These are certainly the most vocal group. The majority of these are transport related. Although they technically violate the XML-RPC specification, we have a history of accepting them as they are easy to enable, and can be disabled by default. In the 2.0 branch (HEAD) there is explicit support for changing the transport used on both the client and the server side. Furthermore, not all of these patches need to be integrated into XML-RPC. The current API provides sufficient support for most of them to be part of the product using XML-RPC rather than part of XML-RPC. Very few patches are submitted with any form of tests or documentation, meet the coding conventions used at Apache, or contain an indication if the standard test suite has been run. This makes it difficult to accept them, as the submitters code already works without changes to XML-RPC, and significant effort is required from committers to develop tests so that other users of the code can have some degree of certainty that the code works. Many of these patches might be better placed in a 'contrib' package, with less stringent guidelines regarding tests and the like. While they are often of use to their submitters, it is unclear (to me at least) if they are necessary (or usable) for other users of the package. A 'contrib' package would be a compromise approach. If it appears that there are a large number of users for a particular feature, then moving it to the core (and developing appropriate tests) can be considered. I certainly feel that for XML-RPC 1.2 (still in a very long beta) and 2.0, patches that effect users of the Java API, or the default transport behaviour of XML-RPC (except to fix interoperability issues) should not be accepted. I have just committed a couple of patches to 1.2 that fix an opens issues, one with input encodings on non-ASCII platforms, the other with the user handler mapping code. I have also reviewed Bugzilla issues open against 1.2 and fixed those that are bugs. I will attempt to close out the remaining issues this week, although with the possible exception of 16450 (for which I am having trouble accessing the patch) none of them merit code changes. I am willing to continue the 1.2 branch to its final release (although I think we need to check which license is to be used) and to commit appropriate (ie. with tests!) patches to 2.0 as they are submitted to the list. Regards, Andrew. -----Original Message----- From: Jochen Wiedmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 30, 2005 8:32 AM To: xmlrpc-dev@ws.apache.org Subject: Re: XML-RPC need maintenance : On Wed, 30 Mar 2005 08:55:15 +0200, Sebastian Dransfeld <[EMAIL PROTECTED]> wrote: > The Collections framework is old now. Who still uses Vector and > Hashtable? I vote for Collections in 2.0. BTW, I sent a patch for this a > while ago. The reason I am for delaying this is as follows: XML-RPC 1.1 is quite old. In fact, a lot of running applications depend on version 2 as it is now. In other words, version 2 deserves a maintenance mode without API changes, unless absolutely required. Jochen -- Outside of a dog, a book is man's best friend. Inside of a dog, its too dark to read. (Groucho Marx)
