Is there an interest for an async JSON-RPC library in boost ?
A couple of years ago, I wrote packio, a library implementing asynchronous client and server for msgpack-rpc. Over time it evolved into something more generic, an async implementation of the JSON-RPC (https://www.jsonrpc.org/) spec with customizable serialization. It is built on top of asio, and boost.json is supported serializer. This means that with minimal efforts it could evolve into an implementation of JSON-RPC with no dependencies outside of boost - yet extendable. My question then is: is there an interest for it ? I'd probably need to invest a non trivial amount of time into making it boost-compliant and following up on the review process, so I'm wondering whether it is worth it or not. Note that there are two known limitations in my library: - No support for batch mode - No support for sharing a transport between a client and a server (not part of the spec, but requested by some users) I'm looking forward to get the community's opinion. You can check my library on GitHub (https://github.com/qchateau/packio). Feedback on either community's interest for such library, or plain comments on the library are welcome ! Quentin
On Thu, Apr 11, 2024 at 3:23 AM Quentin Chateau via Boost
A couple of years ago, I wrote packio, a library implementing asynchronous client and server for msgpack-rpc. Over time it evolved into something more generic, an async implementation of the JSON-RPC (https://www.jsonrpc.org/) spec with customizable serialization.
It is built on top of asio, and boost.json is supported serializer. This means that with minimal efforts it could evolve into an implementation of JSON-RPC with no dependencies outside of boost - yet extendable.
My question then is: is there an interest for it ? I'd probably need to invest a non trivial amount of time into making it boost-compliant and following up on the review process, so I'm wondering whether it is worth it or not.
I'd be interested in this library. But you're right, you're in for a lot of work and then an intense review process.
Note that there are two known limitations in my library: - No support for batch mode
May I ask if you plan to support it in the future?
- No support for sharing a transport between a client and a server (not part of the spec, but requested by some users)
I'm looking forward to get the community's opinion. You can check my library on GitHub (https://github.com/qchateau/packio). Feedback on either community's interest for such library, or plain comments on the library are welcome !
Below are my thoughts when first looking at the example code - can your library be used with a beast websocket? server->dispatcher()->add_async( "multiply", {allow_extra_arguments, "a", "b"_arg = 2}, [&io](completion_handler complete, int a, int b) { // Call the completion handler later packio::net::post( io, [a, b, complete = std::move(complete)]() mutable { complete(a * b); }); }); Do I need to post here to avoid recursion? Is completion_handler an alias for asio::any_completion_handler? How do I handle errors? I.e. custom json-rpc server errors. server->dispatcher()->add_coro( "pow", io, [](int a, int b) -> packio::net::awaitable<int> { co_return std::pow(a, b); }) How do I do error handling here? Throw an exception? I would be very much interested in system::error_code. Also: is there anything special about this function, or is it just a convenience to avoid writing add_async with an asio::co_spawn? Does async_serve_forever support asio::cancellation_slot? std::tuple{arg("a") = 42, "b"_arg = 24}, I am not a fan of that syntax. I'd prefer {{"a", 42}, {"b", 24}}
Quentin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
From my experience JSON-RPC is rarely/ever used. It was one of the early things I implemented back in the days for CppCMS.
From the server side for example you want to run behind server specific communication, usually http but it can also be fastcgi, scgi - that is why middle-layer of http
Nowadays a much more common interface that is being used between client/server and services in general is REST (or its OpenAPI implementation). Also I'd recommend implementing it behind some HTTP/HTTPs implementation rather that over plain socket. From user perspective there should be no difference weather you communicate over SSL or not. Over HTTP/1.1, HTTP/2.0 or others. protocol implementation is necessary - even for more things like authentication, cookies and more. Because when you run some RPC request you need some security layer. This is usually handled by the library than handles HTTP itself (or its derivatives). I don't mean to discourage you but just to show the dimension of the problem. And of course consider that other methods are way more common than JSON-RPC. Artyom On Wed, Apr 10, 2024 at 10:23 PM Quentin Chateau via Boost < boost@lists.boost.org> wrote:
A couple of years ago, I wrote packio, a library implementing asynchronous client and server for msgpack-rpc. Over time it evolved into something more generic, an async implementation of the JSON-RPC (https://www.jsonrpc.org/ ) spec with customizable serialization.
It is built on top of asio, and boost.json is supported serializer. This means that with minimal efforts it could evolve into an implementation of JSON-RPC with no dependencies outside of boost - yet extendable.
Le 2024-04-11 16:20, Artyom Beilis via Boost a écrit :
From my experience JSON-RPC is rarely/ever used. It was one of the early things I implemented back in the days for CppCMS.
Nowadays a much more common interface that is being used between client/server and services in general is REST (or its OpenAPI implementation).
Also I'd recommend implementing it behind some HTTP/HTTPs implementation rather that over plain socket. From user perspective there should be no difference weather you communicate over SSL or not. Over HTTP/1.1, HTTP/2.0 or others.
I'll actually think of quite the opposite. I could be interested in a transport agnostic json rpc interface. Let me deal with the transport, what i wish from a server json rpc library is : * it does the parsing of json rpc, incrementally * it allows me to register method handlers, which are called when the corresponding method is received * separation between the configuration and the parser (one single shared configuration, and multiple (1 per client) server channels which uses the same configuration) * it produce replies (ie, is able to json-serialize, potentially via describe) from the return value of the called handlers or whatever mechanism it wishes, either synchronously or asynchronously, as buffers of chars
From the server side for example you want to run behind server specific communication, usually http but it can also be fastcgi, scgi - that is why middle-layer of http protocol implementation is necessary - even for more things like authentication, cookies and more. Because when you run some RPC request you need some security layer. This is usually handled by the library than handles HTTP itself (or its derivatives).
To me it looks a lot more like a reason for not doing it in the library. Provide a jsonrpc facility, that can run over any text stream (including a basic text file, actually just consume a bunch of chars), and let the user choose whatever is the best fit for the transport. This also makes the whole stuff a lot easier to test. In that vision, asio is not relevant anymore. But an asio raw tcp implementation can be built on top of that, like would an implementation on top of beast, or http2, or whatever. It makes a lot of sense to provide them, but it also makes a lot of sense to not require them to use the library.
A couple of years ago, I wrote packio, a library implementing asynchronous client and server for msgpack-rpc. Over time it evolved into something more generic, an async implementation of the JSON-RPC (https://www.jsonrpc.org/ ) >> spec with customizable serialization.
It is built on top of asio, and boost.json is supported serializer. This means that with minimal efforts it could evolve into an implementation of JSON-RPC with no dependencies outside of boost - yet extendable.
Custom serialization may be relevant for some users, but custom transport is more relevant for my use case. Regards, Julien
In that vision, asio is not relevant anymore. But an asio raw tcp implementation can be built on top of that, like would an implementation on top of beast, or http2, or whatever. It makes a lot of sense to provide them, but it also makes a lot of sense to not require them to use the library.
:thumbs-up: This would make the library interesting/more usable and better-suited as a Boost library. - Christian
One of the exchanges I connect to uses JSON-RPC 2.0. I might find it useful. On Wed, 10 Apr 2024 at 21:23, Quentin Chateau via Boost < boost@lists.boost.org> wrote:
A couple of years ago, I wrote packio, a library implementing asynchronous client and server for msgpack-rpc. Over time it evolved into something more generic, an async implementation of the JSON-RPC (https://www.jsonrpc.org/ ) spec with customizable serialization.
It is built on top of asio, and boost.json is supported serializer. This means that with minimal efforts it could evolve into an implementation of JSON-RPC with no dependencies outside of boost - yet extendable.
My question then is: is there an interest for it ? I'd probably need to invest a non trivial amount of time into making it boost-compliant and following up on the review process, so I'm wondering whether it is worth it or not.
Note that there are two known limitations in my library: - No support for batch mode - No support for sharing a transport between a client and a server (not part of the spec, but requested by some users)
I'm looking forward to get the community's opinion. You can check my library on GitHub (https://github.com/qchateau/packio). Feedback on either community's interest for such library, or plain comments on the library are welcome !
Quentin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
Artyom Beilis -
Christian Mazakas -
Julien Blanc -
Klemens Morgenstern -
Quentin Chateau -
Richard Hodges