Is xmlrpclib slow?

[Graham Dumpleton]

"Magnus Lie Hetland" <mlh at idi.ntnu.no> wrote in message news:<9p2hfi$cic$1 at tyfon.itea.ntnu.no>...
> "Gillou" <nospam at bigfoot.com> wrote in message
> news:9ovlv0$1aaq$1 at norfair.nerim.net...
> [snip]
> > Hope the future xmlrpclib will use the new PyXML package in place of the
> > _nearly deprecated_ xmllib.
> 
> Ah... I didn't realise it used xmllib. (I have expat installed.)
> 
> I guess that's a major factor. By the way, I don't see the need for
> a full XML parser... Isn't the XML-RPC close to SML [1] compliant?

This issue has been hashed out a little bit on the XML-RPC mailing list
before and some there strongly argued that any XML-RPC parser should be
able to accept any XML. Ie., including comments, CDATA etc etc. At the
same time, the XML-RPC specification itself says that some stuff must be
US ASCII only, which is in conflict with the XML specification.

You thus have a situation where some people have implemented client code
which requires CDATA to be understood, yet various XML-RPC servers which
are available don't. Some implementations also ignore the ASCII requirement
and implement UTF-8 and other encodings as well.

Thus, people follow the spirit of the specification more than what it
actually mandates, not that it is clear, as some issues are still open
to interpretation. The specification is basically seen as frozen now,
so don't expect the situation to get any better. The XML-RPC specification
was a nice first try but is lacking a bit. SOAP as a subsequent try however
goes too far and in terms of simplicitly borders on being impractical.

It wouldn't be hard to come up with a slightly better version of XML-RPC
and various people have done so, but it is basically impossible to get
enough momentum to get an alternative adopted in its place. Part of the
reason for this is that certain individuals who have deeply integrated
XML-RPC into their product offerings strongly resist such a change and
subtlely and some times blantantly undermine such attempts to get changes
made.

In practice, RPC over HTTP actually causes more problems than it is worth
in some applications where there are existing alternatives. One is better
off simply staying with the existing techniques, rather than chasing the
latest buzz words.

In short, having a widely adopted version of an RPC over HTTP mechanism
based on something like SML might be a good idea, but it ain't going to
happen.