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?
Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -