You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Jochen Wiedmann <jo...@gmail.com> on 2005/04/01 06:24:18 UTC
RFC: XML-RPC 3
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.
Re: RFC: XML-RPC 3
Posted by Jochen Wiedmann <jo...@gmail.com>.
Steve Quint wrote:
> implementations. By default, the current framework *must* not violate
> the XML-RPC specification.
+1
Re: RFC: XML-RPC 3
Posted by Steve Quint <li...@nanohertz.com>.
At 6:24 AM +0200 4/1/05, Jochen Wiedmann wrote:
>
>- 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.
I agree with your suggestion, but strongly disagree with your
statement about inter-operability. Every single patch that I've
submitted has been due to some minor incompatibility with remote
XML-RPC implementations. By default, the current framework *must*
not violate the XML-RPC specification.
--
Steve
------------------------------------------------------------
"Always ... always remember: Less is less. More is more. More is
better. And twice as much is good too. Not enough is bad. And too
much is never enough except when it's just about right."
-- The Tick
------------------------------------------------------------
Re: RFC: XML-RPC 3
Posted by Jochen Wiedmann <jo...@gmail.com>.
Hi, Michael,
On Apr 1, 2005 2:27 PM, Michael Shillinger <ms...@lucent.com> wrote:
> The XmlWriter should be extensible.
in some sense, it already is: See the TypeDecoder class.
However, my vision would indeed be a mapping between element names
(like "i4" or "struct") and SAX ContentHandlers (parsing) or SAX
drivers (writing). I would think this would be what you expect.
> Samples, examples and how-to docs would be extremely helpful for newbies.
Agreed.
> Although it would violate the spec, typing the <struct> element would be
> very helpful.
>
> i.e.
> <struct name="org.mshillin.util.Address">
I believe to understand your wish. My personal vision would be to get
something quite similar with the help of JAXB. Similar things could be
done dynamically with BeTwixt or Digester (both from the Jakarta
Commons).
Jochen
--
Outside of a dog, a book is man's best friend.
Inside of a dog, its too dark to read.
(Groucho Marx)
Re: RFC: XML-RPC 3
Posted by Michael Shillinger <ms...@lucent.com>.
Jochen,
I agree with many of your points.
I would like to add my views.
The XmlWriter should be extensible.
I have been using 1.2 as a base and have made the XmlWriter a
configurable parameter by using a factory. I did this so I could have
automatic conversion between base XML-RPC types and my own classes.
Stream-based would be great.
Samples, examples and how-to docs would be extremely helpful for newbies.
Although it would violate the spec, typing the <struct> element would be
very helpful.
i.e.
<struct name="org.mshillin.util.Address">
Probably wishful thinking on the last one...
Mike
Jochen Wiedmann wrote:
>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.
>
>
>