Weaknesses of XML-RPC
The problem with XML-RPC as an object-serialization format is that it just plain does not have enough types to handle the objects in most high-level programming languages. Listing 4 illustrates this shortcoming.Listing 4. Python shell example of XML-RPC overloading
Listing 4, two things are serialized -- an object instance and a
dictionary. While it is fair to say that Python objects are
particularly dictionary-like, you lose a lot of information by
representing a dictionary and an object in exactly the same way. Additionally, the excessively generic meaning for
in XML-RPC affects pretty much any OOP language, or at least any
language that has native hash/dictionary constructs; it is not a Python
quirk here. On the other hand, failing to distinguish Python tuples and
lists within the
<array> type of XML-RPC is a fairly Python-specific limitation.
xml_pickle handles all the Python types much better
(including data types defined by user classes, as we saw). Actually,
there is no direct pickling of dictionaries in
basically because no one has asked for this (it would be easy to add).
But dictionaries that are object attributes get pickled, as shown in
Another virtue of the
xml_pickle approach that is implied in the example is that dictionary keys need
not be strings. In XML-RPC
<name> keys are always strings. However, Perl, PHP, and most languages are closer to the XML-RPC model in this.