Shane Hathaway wrote:
I feel like the absence of base-64 encoding is an oversight in the protocol, along with the absence of a "null" type (which would correspond to "None".) That's why I think it's not a kludge to extend XML-RPC.
The omission of the explicit null is one of the oldest gripes with XML-RPC (and last time I read up on it, Dave Winer was firmly against its inclusion). It's usually the first thing I add to the "spec" when I'm working with it.
But why is the 30% bloat an issue? The important parts of the base64 module are in C and the encoding and decoding is fast.
Encode/decode speed is fine (using binascii, not base64 ;) Mostly it's network bandwidth issue. We're implementing an "offline management" feature specifically for users who are on the end of a slow link to their server. We're looking at transferring potentially big images. It is therefore a high priority to make the xml-rpc transactions as fast as possible. I'm starting to look around for other mechanisms. I looked into faking file upload form submissions, but Python's support for multipart/form-data is pretty rough - and from my reading, the RFC is rather hazy on the support of unencoded data. Zope to Zope FTP is my next avenue to investigate ;)
In fact it's time to convert xmlrpclib to use the Expat module (via SAX) in Python 2.1. It should speed it up dramatically.
I wish we had the luxury of moving to python 2.1 :(
Actually the sax / expat module is also available for Python 1.5.2, if that helps.
Yeah, as long as there's pre-compiled binaries for win32, I'm happy. I'm currently in VC++ hell trying to get freetype2 and the python ft2_interface compiled for windows. Argh. Oh yeah, another thing I noticed is that the Zope profiling seems to break if an xmlrpc call is invoked. Just hangs when it hits the call. Any clues? Richard -- Richard Jones richard@bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)