Open halayli opened 12 years ago
I am working on an rpc facility to replace/clone 'fast_rpc'. fast_rpc uses cPickle/fpickle, and I'd like to move away from that. When I looked over a few choices, json seemed like a good default choice. The codec is supposed to be fast, and it's simple. But I think it may be possible to build a generic rpc facility with a replacable codec.
I'm planning on making an 'rpc' package, so maybe like this: coro.rpc.json.server, coro.rpc.xml.client ?
Also, xmlrpc probably requires going over HTTP. jsonrpc 2 claims to be transport-agnostic - that it can run over tcp for example, but it still needs a framing mechanism of some kind. I'm building it on top of a slightly modified version of packet_stream.py (uses 8-byte binary length rather than hex-encoded length).
I like the idea of having the 2 options xmlrpc + jsonrpc. Maybe we can use httpd.py to handle requests that require HTTP (xmlrpc)?
Have you seen the new http package? It still has the same 'handler' architecture, but the behavior of request objects has changed, they actually handle content-containing requests in a much more sane fashion, using generators.
So for xmlrpc/jsonrpc over http, you would just need a 'handler'.
This is the one I checked https://github.com/ironport/shrapnel/tree/master/coroutine/httpd . Is there a different one?
I think the handler concept is pretty flexible. I like it.
Yes, see the 'new-httpd branch'. I mentioned on the mailing list the other day that I was planning on merging into main (and thus making coroutine/httpd obsolete). Let me know what you think.
Ah I missed it! I thought google groups will email me new msgs in the group but it didn't. I missed your http + dns related post. I'll reply there :).
Did we forget to include coro's xmlrpc lib or should I port python's xmlrpc ?