Hi,
I'd like to present my view of what XML-RPC could and should be. Please,
read on.
Regards,
Jochen
XML-RPC 3
=========
1.) Status of XML-RPC sources
The current source tree is obviously grown over the years and without
serious attempts to reorganize. The following problems are obvious:
- Code duplication; for example, a lot of code implemented in
SimpleXmlRpcClient and XmlRpc should actually have been moved
to HandlerBase. Another example, user authentication and other
types of HTTP header generation are handled in the various
implementations of XmlRpcTransport, although it could very well
be handled in a common level above.
- Architecture: The dependency between the various classes is
at best non-obvious. In particular, it isn't easy to understand,
what should be configured where and what component reads which
configuration parameters how. Besides, a lot of configuration
settings are stored in static variables (per application),
although they should in fact be per client or even per request.
- Extensibility: The current framework has clearly been designed
with the XML-RPC specification in mind. As a consequence, it
does very well, what it is implemented for. However, it could
do much more: Support for all basic Java types, the null value,
serializable objects or even embedded XML documents (DOM, JDOM,
JAXB) are worth being implemented.
Of course, these would be violating the XML-RPC specification.
However, fact is, that most of us aren't so much interested in
interoperability. A compromise might very well be, that the
extensions are disabled by default and need explicit enabling
by the user. In other words: The user needs to be aware, that
he is violating the specification. Additionally, the violations
could very well be made obvious on the protocol level by
using XML namespaces.
- Performance: This is possibly not so much an issue on the client
side. However, on the server side it definitely is. XML-RPC
has several disadvantages in terms of performance, that could
easily be fixed: In particular, it is based on large internal
strings and byte arrays, although it could easily be completely
streaming. Likewise, several things could easily be implemented
as singletons, although they aren't or at least not by default.
For example, in the recommended configuration, the XmlRpcServer's
XmlHandlerMapping is initialized for any request, although
(depending on the application) this initalization is quite heavy,
if it involves a lot of Java reflection. A better approach would
be using singletons.
2.) Goals and Non-goals
- XML-RPC 3 would *not* be defined for source code compatibility.
Compatibility would be an issue, but not necessary. If required,
porting should be easy.
- In view of the above, XML-RPC 3 would be defined for Java 1.3 and
JAXP 1.1. In particular, it would use a SAX 2 parser (possibly
still including MinML and a suitable adapter) and support the
Java collections framework. Arrays, Lists would be synonyms.
Vectors and Hashtables would be special cases of Lists and Maps.
- Implementation is completely based on SAX, aka streams. Unless
necessary, no internal byte arrays or large strings are created.
- XML-RPC 3 should have a clearly defined architecture, based on
the following objects. (For the sake of simplicity, I describe
the client, although this is obviously applicable to the server.)
A new "configuration" object is being created. The purpose of
the object is to hold per request data: Server URL, credentials,
encoding, requested compression, whether to enable extensions,
and so on. For use by derived factories, it should also contain
a method
String getProperty(String);
The purpose of the "configuration" object is being passed through
the various methods. For example,
XmlRpcHandler.execute(String, Vector);
would become
XmlRpcHandler.execute(Configuration, String, List);
A typical application would use a singleton configuration.
Moreover, it would possibly just use an instance of XmlRpcClient
with an implicit configuration and the method
client.execute(String, List)
which would simply be a shortcut for
client.execute(client.getConfiguration(), String, List);
The clients role would be basically reduced to an object factory.
By default, most objects would be implemented as singletons.
(The exception being SAX handlers, which need state.) In particular,
the XmlHandlerMapping could easily be made a singleton.
- Ease of use: A default servlet would be added, which takes as input
a list of classes (from a property file, or something similar), which
are being exposed as handler classes.
