From: "João Távora" <joaotavora@gmail.com>
To: "Clément Pit-Claudel" <cpitclaudel@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: jsonrpc.el closer to merging
Date: Mon, 11 Jun 2018 15:42:35 +0100 [thread overview]
Message-ID: <CALDnm52oFocyGA8uQKkO4BymjCPjZew41GEraRaAU97ev_DzhA@mail.gmail.com> (raw)
In-Reply-To: <6733499b-b27f-0886-2e8d-bb59c59ace74@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]
[Clément, sorry if you are getting this in duplicate]
On Mon, Jun 11, 2018 at 2:08 PM, Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:
> 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
[-- Attachment #2: Type: text/html, Size: 7319 bytes --]
next prev parent reply other threads:[~2018-06-11 14:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-10 15:56 jsonrpc.el closer to merging João Távora
2018-06-10 17:56 ` Clément Pit-Claudel
2018-06-10 22:36 ` João Távora
2018-06-11 13:08 ` Clément Pit-Claudel
2018-06-11 14:42 ` João Távora [this message]
2018-06-11 22:26 ` João Távora
2018-06-11 23:13 ` Clément Pit-Claudel
2018-06-13 10:19 ` João Távora
2018-06-11 1:46 ` Stefan Monnier
2018-06-11 6:34 ` João Távora
2018-06-11 12:30 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALDnm52oFocyGA8uQKkO4BymjCPjZew41GEraRaAU97ev_DzhA@mail.gmail.com \
--to=joaotavora@gmail.com \
--cc=cpitclaudel@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.