Jochen Wiedemann wrote: > Christoph Theis wrote: >> - ServerInputStream.java: Make this class public. >> This is a really minor change :) > What for?
Why is java.util.prefs.Base64 not public? :( Both are very handy classes. I need it because I have to write my own XmlRpcTransport class to add a cookie to the requests. LiteXmlRpcTransport: If we could add additional headers to requests I could use the LiteXmlRpcTransport class. And a nice feature would be if the constructor would setup authorization info from the URL argument. At the moment I could live with my class (almost copied from LiteXmlRpcTransport) but I want to avoid to copy ServerInputStream too, just because it is not public. >> - Invoker.java: Allow for void methods. >> This class is very handy if you want to invoke methods in an >> arbitrary object. Unfortunately the method can't be a void method, >> yet. Therefore calling e.g. "JTextPane.setText" is not possible. >> I have a patch for this but since the project was very quiet I did >> not bother to submit it yet. > Important question: Does the SPEC know void methods? The spec does not allow for void methods. So the default is to throw an exception if the method is void. But, like ServerInputStream, it's very useful to call a method "by name". In my case I get a function name in the request, try to invoke that method in the object that can be any Object, e.g. Swing Widget, and I return a dummy value, if the method was void. So I still adhere to the spec. > Depending on the patch, I can imagine to commit it immediately. This > would be sufficient for 2.0. I wouldn't see this as a blocker for 2.0. OK, I will submit the patch. >> - XmlRpcWriter.java: What about non-ASCII characters? The latest >> XMLRPC-spec allows for it. > Are there any changes in the SPEC you are referencing? Besides, I'm not > aware of any limitations in the code, which would prevent non-ASCII > characters. Or do you mean non-printable characters? The original spec allowed ASCII characters only for strings. The word "ASCII" ws removed 2003. XmlWriter still checks for the range 0x20 ... 0xff and not for the range allowed by the XML spec. There had been a lot of discussion over this the last years and as far as I know Apaches (our) xmlrpc still clings to ASCII characters. But might be I'm wrong ... Christoph
