Progress notification

[arek]

Hi,

I was wondering whether jsonrpc should have another kind of response
apart from existing 'result' and 'error'.
I am thinking about 'progress' key.

The scenario is as follows:

--> {"jsonrpc": "2.0", "method": "long_task", "params": [42, 23],
"id": 1}
<-- {"jsonrpc": "2.0", "progress": "Doing step 1/3", "id": 1}
<-- {"jsonrpc": "2.0", "progress": "Doing step 2/3", "id": 1}
<-- {"jsonrpc": "2.0", "progress": "Doing step 2/3: loaded 30%", "id":
1}
<-- {"jsonrpc": "2.0", "progress": "Doing step 2/3: loaded 90%", "id":
1}
<-- {"jsonrpc": "2.0", "progress": "Doing step 3/3", "id": 1}
<-- {"jsonrpc": "2.0", "result": "OK", "id": 1}

Please note that "id" is mandatory since it allows to corelate
progress notification with original request.

As for other solution i was thinking (but considering as bad idea):
- sending multiple 'result', and handling progress at application
level
I do not like this. 'result' should be final that is one and only
for the given request
- using 'Notifications' and handling progress at application level
Don not like this even more :) It would require that client should
be a server to receive such notifications.
Moreover, corelation with original request had to be dane at
application level

I believe such enhancement (adding "progress") would be most elegant
solution ...
Maybe it would require new jsonrpc release (jsonrpc-3.0 ?)

Please tell me what you think.

[Matt (MPCM)]

You are making a lot of assumptions about the capabilities of the
servers I've currently seen to even do something like this. What you
are suggesting would be elegant to the client, it would require a
certain architecture by the server, which would very much complicate
the server role and makes certain assumptions about the transports.

Servers cannot just send messages to a client, nor should they do so
using the same id, that would be very confusing I think.

I'd recommend you implement this using multiple request/responses and
implementing this first, then bringing back any suggestions and
thoughts on how to handle a situations like this on the server side.
If there is a compelling case to add it to json-rpc, we can have those
discussions them.

Personally I'd be very much against adding this to the spec for a
variety of reasons, but would love to see someone using a setup like
this using multiple request/responses in practice.

--
Matt

[Jakob Simon-Gaarde]

You can achieve something similar by creating a method that can start a task in the background and return a task id which can be used as input to a poll method. You will need to make your background publish it's progress somehow (ie. Using the file system) for the poll method to use.
best regards Jakob Simon-Gaarde

> --
> You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
> To post to this group, send email to json...@googlegroups.com.
> To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.
>

[Rasjid Wilcox]

Hi Arek,

You can essentially already do this with my JsonRpc implementation,
and possibly with some (all?) of the other bi-directional over tcp
implementations. Note that rather than adding to the spec, my
solution depends on both ends of the connection being both a jsonrpc
client and a jsonrpc server at the same time (ie, a peer arrangement).
(I see that this is one of your 'not preferred' solutions.)

Anyway, you can see
http://www.openminddev.net/rpcbd/python/callback_examples.html for
some examples.

Cheers,

Rasjid.

[Alexander Prokhorov]

I know that six years have passed, but personally I like an idea of having `progress` and intermediate replies. Today, when WebSockets are everywhere, it is completely normal to send notifications from the server side. I would like to use jsonrpc 2, but it does not cover progress notifications which are important in my case. So I think I will adopt your idea in the server I now work on )

среда, 8 июня 2011 г., 13:43:42 UTC+4 пользователь arek написал:

[Matt (MPCM)]

I am using something like this pattern across transports (http + websockets), but still adhering to the 2.0 spec concepts.

API calls are usually non-blocking http by default.

After some initial validation + rate limiting/queue-depth-limiting, it drops the msg in a queue and returns an initial result that contains an accepted but pending state and possibly some actionable response data.

Using a service like pusher.com, workers draining the queue share pending/still_working_on/completed notifications on a per APIKEY dedicated channel.

If a customer really wants/needs a blocking version like a more traditional HTTP api... they send the request to an endpoint (or signal that desire in the headers), which will block for them, make the api call, listen on the channel, then connect them through... hopefully within the HTTP window.

This way customers can choose to listen for more updates depending on their visibility needs.

- dashboards watch and react to everything

- clients calling in from the field offload quickly with async jobs that might be long-running/time-delayed/waiting-on-scaling-event

Please post back about what you implement, how it goes, and your experiences/thoughts. :)

[Andrew Arnott]

I am proposing an extension to the JSON-RPC 2.0 spec for progress updates that precede the final result message for a request.

https://github.com/Microsoft/vs-streamjsonrpc/issues/139

Your feedback is welcome.