Feature proposal - unsolicited notifications

[weili-jiang]

I am currently using packio as a JSON RPC client in a commercial project. The server is a custom JSON RPC implementation that sends unsolicited notifications. This behaviour is outside the JSON RPC specification, but we have no control over the server. Other libraries have implemented this extension - see https://github.com/joncol/jcon-cpp as an example.

I have implemented the client-side support for this, extending the client class using the existing dispatcher class used by the server. We have been using this successfully over the last couple of months. What we have not done:

• Server support for sending such notifications
• Testing for Boost JSON and MessagePack variants (our project uses JSON for Modern C++)
• Packio tests

Before I do any further work - would you be interested in a PR for this feature?

[qchateau]

Hi,

While I don't mind evolution, I don't want to implement a behavior that is specific to packio, as I want to provide a standard implementation so that servers and clients can be implemented in different languages, using different libraries.
I get that this feature would be opt-in, but the point still stands. If I implement your feature today and tomorrow someone else comes up with the same request, but a slightly different protocol, it would be embarassing.

You mention an extension used by other libraries (plural). Is there any kind of specification for it ? How many libraries support it ? Is this an extension that can be found in other languages ?

Before committing to a protocol to implement this feature, I'd like to asses how standard and reusable it would be

[weili-jiang]

Perhaps I did not describe it properly. It is more like bidirectional JSON RPC, where a server and client may exist on the same transport.

The basic concept is that while JSON RPC is client-server per request/response, there is no specific restriction that says a particular transport is stuck with a single server on one end and client on the other. The same socket may be used to send both client and server type messages. So actually, it is within JSON RPC specification, just a particular interpretation of it.

Some libraries, e.g. https://github.com/joncol/jcon-cpp simply allow you to send notifications from the server instance and handle them in the client. I went with this approach for packio as it represented minimal interface change to the existing API without breaking changes.

Most separate the server/client role from the transport entirely so you are free to do either on the same socket, e.g

.NET: https://www.npmjs.com/package/vscode-jsonrpc

JS: https://www.nuget.org/packages/streamjsonrpc

Perl: https://metacpan.org/pod/JSON::RPC2::TwoWay

Dart: https://pub.dev/packages/json_rpc_2

Go: https://pkg.go.dev/golang.org/x/tools/internal/jsonrpc2

If you Google bidirectional JSON RPC there are lots of examples.