Christoph Theis wrote: > Why is java.util.prefs.Base64 not public? :(
No idea. The difference being, that I see a use case for the Base64 class, but not for the ServerInputStream. :-) > I need it because I have to write my own XmlRpcTransport class > to add a cookie to the requests. That should much more easy to be done using one of the existing classes, isn't it? > 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. I see access to the headers as a very reasonable desire. In other words, I'd be ready to discuss and possibly apply patches in that direction, if no one else intervenes. I see no sense, though, in making the ServerInputStram public. > The spec does not allow for void methods. So the default is to throw > an exception if the method is void. In that case, I suggest to defer that to 3.0, where at least I plan to add a lot of extensions to the SPEC. (The default always being compliant to the SPEC, of course.) > 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 ... If XMLWriter does check for 0x20 to 0xff, it does the wrong thing anyways, because ASCII is 7 bit only. In other words, I'd be +1 for opening this. Again, if this would be in violation of the SPEC, then I'd be +1 for deferring it to 3.0. Jochen
