> [EMAIL PROTECTED] wrote: > Guys. This can be done with sane XML-RPC request/response objects > (think servlets) and an interceptor API, instead of creating N endpoint > implementations.
In what way are XmlRpcRequest and XmlRpcClientRequest objects not 'sane'? Why is having n implementations for n transports a bad thing? HTTP, HTTPS, Jabber, SMTP, BEEP, etc share very little in common, and all bring in different libraries to link against. The potential for re-use is low, so forcing it may do more harm than good. > This horse has _so_ left the barn. > For reference: http://aeolus.cit.cornell.edu/pub/xmlrpc/xmlrpc.html ( > way way out of date, but look at the interceptor API for reference, the > signatures could be condensed with request/response objects; also > see example). I don't see how this could be used to implement XML-RPC over any transport other than cleartext HTTP. The patch is not only not up-to-date, but it seems to have been generated incorrectly. eg. a chunk from WebServer.java @@ -245,8 +264,8 @@ } catch (Exception x) { - throw new IllegalArgumentException("\"" + - address + + throw new IllegalArgumentException("\"" + + address + "\" does not represent a valid IP address"); } This chunk does nothing except take up space. > People who want to tweak the transport without > engaging in religious wars can do so without affecting anybody else > or forking with respect to endpoints, and having to modify their code > to support some one-off client or server API. While 'interceptors' allow you to do some of what is mentioned, they introduce more problems than they solve. Now you have 6 callouts throughout the framework. What happens if you need a 7th callout, or want to change the signature on one of the methods? You end up with a fork, _and_ you break everyone else's interceptors. Most of what happens with interceptors you can implement by either: a) Stacking handlers on the server side. b) Stacking your own transport on top of a standard transport. (eg. to implement incompatible features). c) Writing your own transport. I can't see why writing an interceptor is any easier than writing a transport. A transport can be written easily in a thread safe manner, and multiple threading models are available (look at how the factory works). An interceptor that needs state could become very difficult to implement. My understanding is that the majority of developers are interested in making compatible implementations, not introducing incompatibilities. They use XML-RPC so that they can work with applications in other languages, or as a simple, standard protocol inside their system. Those that do want to use extensions to the specification are interested in embedding XML-RPC into a larger application, and integrating with the application's protocol stack. In these cases the XmlRpcTransport interface on the client side is often sufficient. Server side transport handling is, and always will be, much more complicated. A server is far more than a function call. This is why classes like XmlRpcRequestProcessor and XmlRpcResponseProcessor are available. These will decode requests and encode responses from a server perspective. If you want to do something incompatible with the transport, embed these classes and you will at least be somewhat compatible. They and their client side counterparts can be used to embed XML-RPC in any transport you wish, with or without 'interceptors'. Andrew.
