> >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. > > So if I've submitted patches that meet the coding conventions, with a > submitted Junit test, and is useful to others, I should submit them > again? Or should I use JIRA for that?
I've looked at your patches, and I think that they both deserve inclusion in some form. The patch to DateTool really does need tests to go with it, dates are extra-ordinarily difficult things (I work for a scheduling company, I KNOW!). > Would preventing randomly thrown Exceptions when parsing bad/weird > XML-RPC responses be considered "useful"? I don't want to get into a > discussion about how everyone should adhere strictly to the spec. > There are different interpretations of the spec, and I can't change > everyone's interpretations of it. All I know is that I need the > library to work with vendor X, and I think my changes would help > anyone else who wants to work with vendor X. Being able to put up with erroneous interpretations of the specification is certainly an advantage. I'd rather have the option of specifying the 'default' value for cases where the cdata is null or empty. This would also provide behaviour for dates and strings as well. Watch this list for a patch to DefaultTypeFactory that allows this. > I *have* been able to work around the problem by using the > "sufficient support" in the current API you mentioned, until I ran > into the encoding issue. Thanks for the patch. Which encoding issue? The default input encoding stuff I fixed today? Andrew.
