[Clément, sorry if you are getting this in duplicate]
On 2018-06-10 18:36, João Távora wrote:
> Yes. Both endpoints can send requests that wait for responses, and
> notifications that don't. JSONRPC doesn't distinguish between clients
> and servers, though the application may do so (eglot.el does, for
> example).
Ah, neat. But then I'm confused. The spec you linked to (http://www.jsonrpc.org/specification ) does distinguish, and there it seemed that only the client could send notifications.
I'm sorry, I totally confused you. But I'm still more or less right, I
think:
" 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. "
jsonrpc.el is one such implementation :-)
> Not sure I follow. In JSONRPC (and in most connection-oriented
> protocols) a response, by definition, something that a request waits on.
> Once it occurs the request is considered completed. jsonrpc.el has two
> ways to model this: jsonrpc-request, blocking and jsonrpc-async-request,
> a non-blocking.
>
> The remote endpoint can send more notifications after responding. Or
> the client can trigger more requests after it get its first response.
Thanks. The context is that I'm trying to see what I need to change to use your library.
I have code in which the server responds with progress information as it processes a query. For example
-> (id=xyz) Compute \pi to 15 decimals
<- (id=xyz, progress) 10% done
<- (id=xyz, progress) 60% done
<- (id=xyz, response) 3.141592653589793
The same lambda gets invoked three times, twice with 'progress and a message, and once with 'done and a number.
Is there a way to model this is json-rpc.el?
Hmm, I see. No the library doesn't allow this (and neither does
JSONRPC, I think)
There's two ways you can do this (in pseudocode)
(require 'cl-lib)
(let (retval
(calculation-id (symbol-name (gensym))))
(while
(cl-destructuring-bind (&key progress result)
(jsonrpc-request conn
:compute-pi `(:id ,calculation-id :decimals 15))
(setq retval result)
(and progress (message "%s" progress)))))
This would make n requests and n responses and the request handler on
the other side must find the calculation id.
The other way would be much simpler and much more JSONRPC'esque would be
to issue notifications while the client is waiting for the answer:
(jsonrpc-request conn :compuate-pi `(:decimals 15))
This blocks until the final response is gotten, but you get to handle
the progress notifications in a separate notification handler. Is there
some ambiguous situation where you would not be able to to correlate
them to the request?
Why don't you tell me, in pseudo-code, how you would like it to work?
Perhaps we can add that as a JSONRPC extension (there's a version
that I'm not using).
João