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
|
In
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 <struct>
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 xml_pickle
,
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
Listing 5.
|
Another virtue of the xml_pickle
approach that is implied in the example is that dictionary keys need
not be strings. In XML-RPC <struct>
elements, <name>
keys are always strings. However, Perl, PHP, and most languages are closer to the XML-RPC model in this.
View XML-RPC as object model Discussion
Page: 1 2 3 4 5 6 Next Page: Weaknesses of xml_pickle