Re: [Zope-dev] xmlrpc: Syntax error at line 34: illegal characterin content

2001-05-10 Thread Shane Hathaway

On Fri, 11 May 2001 [EMAIL PROTECTED] wrote:

 Shane Hathaway wrote:
  The problem with sending binary data unencoded is line endings: \r\n
  might be helpfully converted to \n and vice-versa.  Other characters
  can be encoded but apparently parsers treat #10; and #13;#10; as a
  real line ending.

 I'm not sure where this leaves me... I think this means that ultimately
 it's not possible to send binary data which contains 0x10 or 0x1310 in an
 XML-RPC message. Bummer. Especially with the ~30% bloat incurred by base64
 encoding :(

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.

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.

  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.

Shane


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] xmlrpc: Syntax error at line 34: illegal characterin content

2001-05-10 Thread richard

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
[EMAIL PROTECTED]
Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )