Skip Montanaro wrote:
> That's fine, so XML-RPC is slower than Gherkin. I can't run the Gherkin
> code, but my XML-RPC numbers are a bit different than yours:
>
> XMLRPC encode 0.65 seconds
> XMLRPC decode 2.61 seconds
>
> That leads me to believe you're not using any sort of C XML decode
Simon> I hacked things a bit, and instead of sending XML, sent pickles
Simon> inside the XML response.
I've done the same thing (I think I may have used marshal). It works fine
as long as you know both ends are Python.
Skip
___
Python-Dev mail
> I use XML-RPC as the communications protocol between an Apache web server
> and a middleware piece that talks to a MySQL database. The web server
> contains a mixture of CGI scripts written in Python and two websites written
> in Mason (Apache+mod_perl). Performance is fine. Give either of the
Simon> XML is simply not suitable for database appplications, real time
Simon> data capture and game/entertainment applications.
I use XML-RPC as the communications protocol between an Apache web server
and a middleware piece that talks to a MySQL database. The web server
contains a mixt
Simon Wittber <[EMAIL PROTECTED]> wrote:
> > Why this discussion of yet another serialization format?
>
> Pickle is stated to be unsafe. Marshal is also stated to be unsafe.
> XML can be bloated, and XML+gzip is quite slow.
>
> Do size,speed, and security features have to mutually exclusive? No,
> Why this discussion of yet another serialization format?
Pickle is stated to be unsafe. Marshal is also stated to be unsafe.
XML can be bloated, and XML+gzip is quite slow.
Do size,speed, and security features have to mutually exclusive? No,
that possibly is why people have had to invent their
Why this discussion of yet another serialization format? The wire-encoding
for XML-RPC is quite stable, handles all the basic Python types proposed in
the proto-PEP, and is highly interoperable. If performance is an issue,
make sure you have a C-based accelerator module like sgmlop installed. I
> The RFE suggests that "the protocol is specified in the documentation,
> precisely enough to write interoperating implementations in other
> languages". If interoperability with other languages is really the
> issue, use an existing format like JSON.
JSON is slow (this is true of the python vers
Please don't invent new serialization formats. I think we have enough
of those already.
The RFE suggests that "the protocol is specified in the documentation,
precisely enough to write interoperating implementations in other
languages". If interoperability with other languages is really the
issue,
Hello Chaps,
The attached PEP (pep.txt) is for RFE 46738, which you can view here:
http://sourceforge.net/tracker/index.php?func=detail&aid=467384&group_id=5470&atid=355470
It provides a safe, documented class for serialization of simple python types.
A sample implementation is also attached (g
10 matches
Mail list logo
