Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature proposal - unsolicited notifications #71

Open
weili-jiang opened this issue Dec 21, 2022 · 2 comments
Open

Feature proposal - unsolicited notifications #71

weili-jiang opened this issue Dec 21, 2022 · 2 comments

Comments

@weili-jiang
Copy link

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
Copy link
Owner

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants