simple-json-rpc icon indicating copy to clipboard operation
simple-json-rpc copied to clipboard

Feature: Sending notifications from a server to a client

Open mnasyrov opened this issue 8 years ago • 3 comments

Hi! Thank you for the library!

It would be great to have an ability to build notifications using simple-json-rpc-server jar only.

Now I have to include simple-json-rpc-client dependency and use JsonRpcClient with NotificationRequestBuilder only for building a notification. I also have to emulate Transport for JsonRpcClient. All I need for this case is having NotificationRequestBuilder in the server jar which can build a notification in a string form.

mnasyrov avatar Dec 10 '17 10:12 mnasyrov

Thank you for your interest in the library! Could you elaborate a little more about your use case? If I understand the protocol correctly, the server must not send anything back to the client to a notification request. Do you want to use NotificationRequestBuilder for testing the server?

arteam avatar Dec 11 '17 19:12 arteam

There are client/server apps which communicate over web sockets using JSON-RPC. Clients perform some server's methods and listen for a few server's notifications. Since a web socket is a bidirectional transport nothing blocks to push events from a server to clients :)

JSON-RPC 2.0 specification describes client and server only as roles for peers which is mainly used to illustrate request-response flow:

The Client is defined as the origin of Request objects and the handler of Response objects. The Server is defined as the origin of Response objects and the handler of Request objects.

One implementation of this specification could easily fill both of those roles, even at the same time, to other different clients or the same client. This specification does not address that layer of complexity.

It sounds like it may require to combine all stuff in a single library, so it'll be a good start if NotificationRequestBuilder and other builders be able to return a text request.

mnasyrov avatar Dec 12 '17 04:12 mnasyrov

Thanks for the explanation! It seems to me that in your use case it makes sense to include the client library to your server code base, because it plays two roles: a receiver and a sender. To be honest, I don't have plans to build an uber-jar with both parts, because I presume most of users require either the client or the server implementation. Nevertheless, I will think about simplifying NotificationRequestBuilder, so it should be possible to build requests as strings without using Transport.

arteam avatar Dec 13 '17 20:12 arteam