The future of this library

[bcb]

With the jsonrpcserver rebuild nearly finished I'm starting to turn my attention to this client library.

The main problem with this library is it's trying to support a set of frameworks (aiohttp, requests, socket, tornado, websockets and zeromq), which brings a number of problems:

1. It's limited to the few protocols/frameworks.
2. It supports them with varying degrees of success, some very poorly (websockets).
3. The user doesn't have control of how the transport works.
4. Breaking changes to one of the clients requires a whole new major version of jsonrpcclient.

jsonrpcserver is a better library because it simply processes a JSON-RPC request and that's all. The user handles receiving the request and sending back the response.

So in the next version of jsonrpcclient I want to remove the sending & receiving.

1. jsonrpcclient helps you generate a JSON-RPC request
2. The user sends the request and receives a response - removed from jsonrpcclient
3. jsonrpcclient helps you parse the JSON-RPC response.

Using the library with "requests" would look something like:

from jsonrpcclient import request, parse
import requests

response = requests.post("https://random.org/", json=request("ping"))

# Python 3.10
match parse(response.json()):
    case Success(result, id):
        …
    case Error(code, message, data, id):
        …

One could write a wrapper to send and parse a request, but that would be up to the user.

Interested to hear others thoughts as this would be a major overhaul.

[bcb]

How I picture generating requests:

(Removed because it may change)

[bcb]

Beginning work on this today.

[bcb]

Releases are available, see discussion.

[embray]

Hmm, I thought a while back I wrote a comment here about this plan, but maybe I never sent it. At first I was going to say that the old Client class was very useful at least for having the request() and notify() methods, and that it could hide more advanced logic like out-of-order requests (i.e. #154).

That said, having seen the end results of this refactoring, I like it and it makes the library much simpler and more easily reusable, so congrats! The examples help too. I wonder if it wouldn't still make sense to add some more advanced examples (I could provide one) demonstrating something like #154 involving asynchronous responses, but maybe it's not so common (which I find surprising, but maybe that's just me being overly focused on my use case :)

[bcb]

Yes I think you did mention this @embray

Re the hiding advanced logic, you could definitely write a function that wraps the functionality, (e.g. generates and sends a request, receives and parses the response) all in one. But since there are so many protocols and different ways to use them I think it's best left to the user.

You might even say there's no need for this library any more because all it does is generate a request (which you can do with json.dumps) and parse the response (which you can do with json.loads) but I do think it's a bit nicer than using those.

For the advanced example it sounds like it could be a blog post, so if you have a blog you could post it there, otherwise you could contribute to mine where I have a bunch of JSON-RPC examples (https://composed.blog/jsonrpc/).