Support Binary payloads ?

[BambOoxX]

Hi, I am trying to use JSONRPC.jl ti build a RPC server between julia and a .NET interface using StreamJSONRPC on the client side.

I am wondering if you considered supporting binary payloads (either using MsgPack.jl, or BSON.jl) ? The second has of course the advantage of not changing the behavior for "light" objects w.r.t pure JSON.

For the record I have other questions asked on the discourse if you have any time https://discourse.julialang.org/t/questions-about-jsonrpc-jl/94745

[davidanthoff]

I’m not entirely sure what that would look like? I don’t think the spec supports that? I guess one would just encode binary data as a string and send it? But in that case, do we really need special support in this package here?

I am not generally opposed, just wondering how that would actually look in practice.

[BambOoxX]

Well I think it really amounts to how a Dict is converted before being sent on the communication pipe. So this is not really specific to JSONRPC itself.

So an important question could be how could one use another (de)serialization technique than the default one in JSONRPC?

I have to admit I tried to use JSONRPC given its role in the Julia vscode extension. I figured this kind of package would be well maintained,given the amount of users.
Basically, it seems to be the most trustworthy RPC package and standard, though lacking binary payload support.

Maybe it could be interesting to have a AbstractRPC package that defines all the tools regardless of the serialization format and transport layer?

IN JSONRPC I like the fact that you can register the notifications and requests, but I could not use dict_readable since the types I need to transport are defined in a package not loading JSONRPC. I wonder if StructTypes could not be leveraged like in JSON3

[BambOoxX]

@davidanthoff I agree that this is not a way forward for this specific package, this should be more for a BSONRPC one.
Although it might be nice to make the AbstractRPC or RPCBase package I mentioned before that could serve as a common ground for multiple RPC protocols. I really like how you organized this here with @dict_readable and such.