I modified JSON-RPC -> jgarzik incorporated code from that -> you've added backwards compatibility.
Stop recommending Dinosaurs when we're at Mammals. It's evolution.
It's even backwards compatible with JSON-RPC if you're a strange person.
Topic: [Wiki] Python JSON-RPC example (Read 2631 times)
What is meant by "rather inefficient"? Speed of serializing/deserializing?
That also, but my understanding is that python-jsonrpc only supports single-request-per-connection HTTP/1.0, whereas jgarzik's bitcoinrpc supports HTTP/1.1 persistent connections.Why do we even recommend JSON-RPC at all?
It's not even an official library for Python and it isn't very good (uses floats and has no persistent connections). We should only be recommending jgarzik's version.
Who recommends it? The proposed summary clearly recommend jgarzik's fork. It is an official library for JSON-RPC. It's not even an official library for Python and it isn't very good (uses floats and has no persistent connections). We should only be recommending jgarzik's version.
For the record, after my wiki edits were reverted, I wash my hands of the matter. I do not participate in edit wars.
Why do we even recommend JSON-RPC at all?
It's not even an official library for Python and it isn't very good (uses floats and has no persistent connections). We should only be recommending jgarzik's version.
It's not even an official library for Python and it isn't very good (uses floats and has no persistent connections). We should only be recommending jgarzik's version.
What is meant by "rather inefficient"? Speed of serializing/deserializing?
I can't imagine that is a significant factor for communicating with bitcoin; if you're running into JSON-RPC bottlenecks (is anybody running into performance bottlenecks due to JSON-RPC yet? If you are, what are you doing?) then the lack of persistent connections, lack of JSON-RPC-2.0-multicall support, or bitcoin single-threaded RPC are likely much, much bigger issues.
I can't imagine that is a significant factor for communicating with bitcoin; if you're running into JSON-RPC bottlenecks (is anybody running into performance bottlenecks due to JSON-RPC yet? If you are, what are you doing?) then the lack of persistent connections, lack of JSON-RPC-2.0-multicall support, or bitcoin single-threaded RPC are likely much, much bigger issues.
Does this wording satisfy everyone?
Quote
For Python, python-jsonrpc is the official JSON-RPC implementation. It automatically generates Python methods for RPC calls. However, due to its design for supporting old versions of Python, it is also rather inefficient. jgarzik has forked it as Python-BitcoinRPC and optimized it for current versions (at least Python 2.6+, though not 3.x). Generally, this version is recommended.
While BitcoinRPC lacks a few obscure features from jsonrpc, software using only the ServiceProxy class can be written the same to work with either version the user might choose to install:
While BitcoinRPC lacks a few obscure features from jsonrpc, software using only the ServiceProxy class can be written the same to work with either version the user might choose to install:
Jump to: