From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: jsonrpc.el closer to merging Date: Mon, 11 Jun 2018 15:42:35 +0100 Message-ID: References: <87sh5uvdnr.fsf@gmail.com> <87k1r6uv3p.fsf@gmail.com> <6733499b-b27f-0886-2e8d-bb59c59ace74@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000df75f3056e5ec366" X-Trace: blaine.gmane.org 1528728602 31890 195.159.176.226 (11 Jun 2018 14:50:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 11 Jun 2018 14:50:02 +0000 (UTC) Cc: emacs-devel To: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 11 16:49:58 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fSO8r-0008By-Hc for ged-emacs-devel@m.gmane.org; Mon, 11 Jun 2018 16:49:57 +0200 Original-Received: from localhost ([::1]:49304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSOAy-0007Lq-I0 for ged-emacs-devel@m.gmane.org; Mon, 11 Jun 2018 10:52:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSO26-00011b-CF for emacs-devel@gnu.org; Mon, 11 Jun 2018 10:42:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fSO24-0000p1-Nx for emacs-devel@gnu.org; Mon, 11 Jun 2018 10:42:58 -0400 Original-Received: from mail-it0-x22c.google.com ([2607:f8b0:4001:c0b::22c]:33743) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fSO24-0000oo-Ei for emacs-devel@gnu.org; Mon, 11 Jun 2018 10:42:56 -0400 Original-Received: by mail-it0-x22c.google.com with SMTP id k17-v6so11481622ita.0 for ; Mon, 11 Jun 2018 07:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hUO5yfmC0PVUXdzLDTzioP7IAho4QMskR/Ra9eR/S8o=; b=qOz2MN2fSRpoIOWcyA0mYVFmNv77McA4LW9/sHstFjrbFOyqfi5KKUx9i98izFmWi+ 30dL1wsEMjkrGYrdbvpakIHnfQPobHcfu7QMsFVpfKyD2H95MPNmpEY76fRsgkSVK/br 15ZrXyrt53A13aY9en3vET6bvJGAnC7FMjvEBfHZguDPgx6eP9fO6kUEcYnvwmZ/kioX yOwSkzZ9ZBaNN0RwZHCCi4zAQKjjCtg1X0GyCiu2cAdJHEnNR2V8OPV2mSQR6rTY4WKA gLvlXhFPut2/xLpFUF32zfQwQDDD5b2TK+r7uUiQEDW+mDlMyo1D7TJbHmKWgkgcbhN+ ofjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hUO5yfmC0PVUXdzLDTzioP7IAho4QMskR/Ra9eR/S8o=; b=jyrpD0wiH+I3im6VQ0gRjuxaYasNXFCiijfGCiXoo0UlZMUKpsFPZEPmp0lWv8RnyF yaRIOrRBWhKAPt7t5n0az44Foqg6AhN05fUYHCz9UudsKGohHOg9rnM5dr+TqgjFP9zi ssYnNy5uc9Sg9f3sjV0hy6fdOh8vn+jbkHSNtDqz8cbjNy5McLDA3WsV8zvQ94kRy6wA wbqyTr9ztmJsxBtGHHJHFno+kxPg0jNZU3c2SxXsdi93jKMLxEU63byv5fy5HnTAmeY3 4W4xXfevsIqFnpwkO9+uGFLDI0dIACT4YjQGPecdbEMpugetjYqnvJCShuqYz5n2dccq IYfQ== X-Gm-Message-State: APt69E1iyYO+bu0cByBGYaOEL+yu7/pviOr5fnjk+ocyF3aXaGELIAZb bbFExSFfbjWAq7daboC2RUiNMgAYPwQ6c7GXeKM= X-Google-Smtp-Source: ADUXVKIa8T6sIS9Fb0xokSYinhvHsvnBlZpIiNHmVeZrsUSH6WmpDuUsjqr4oCKJ5pTQvUtjLJVSD+onBvoV/QxfBfo= X-Received: by 2002:a24:8b81:: with SMTP id g123-v6mr10973592ite.67.1528728175734; Mon, 11 Jun 2018 07:42:55 -0700 (PDT) Original-Received: by 2002:a4f:2246:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 07:42:35 -0700 (PDT) In-Reply-To: <6733499b-b27f-0886-2e8d-bb59c59ace74@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::22c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:226212 Archived-At: --000000000000df75f3056e5ec366 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Cl=C3=A9ment, sorry if you are getting this in duplicate] On Mon, Jun 11, 2018 at 2:08 PM, Cl=C3=A9ment Pit-Claudel wrote: > On 2018-06-10 18:36, Jo=C3=A3o T=C3=A1vora 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 us= e > your library. > I have code in which the server responds with progress information as it > processes a query. For example > > -> (id=3Dxyz) Compute \pi to 15 decimals > <- (id=3Dxyz, progress) 10% done > <- (id=3Dxyz, progress) 60% done > <- (id=3Dxyz, 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=C3=A3o --000000000000df75f3056e5ec366 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Cl=C3=A9m= ent, sorry if you are getting this in duplicate]

<= /span>
On Mon, Jun 11, 2018 at 2:08 PM, Cl=C3=A9ment Pit-Claudel= =C2=A0<cpitclaudel@gmail.com= >=C2=A0wrote:
On 2018-06-= 10 18:36, Jo=C3=A3o T=C3=A1vora wrote:
> Yes.=C2=A0 Both endpoints ca= n send requests that wait for responses, and
> notifications that don= 't.=C2=A0 JSONRPC doesn't distinguish between clients
> and s= ervers, though the application may do so (eglot.el does, for
> exampl= e).

Ah, neat.=C2=A0 But then I'm confused. The spec you l= inked to (http://www.jsonrpc.org/= specification) does distinguish, and there it seemed that only the= client could send notifications.


<= /div>
I'm sorry, I totally = confused you.=C2=A0 But I'm still more or less right, I
think:

=C2=A0 =C2=A0 " The= Client is defined as the origin of Request objects and the
=C2=A0 =C2=A0 handler of Response objects.=C2= =A0 The Server is defined as the origin of
=C2=A0 =C2=A0 Response objects and the handler of Request object= s.
=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 One implementation of this= specification could easily fill both of
=C2=A0 =C2=A0 those roles, even at the same time, to other differe= nt clients or
=C2=A0 =C2=A0 the = same client. "

jsonrpc.el is one such implementation := -)

> Not sure I follow.=C2=A0 In JSON= RPC (and in most connection-oriented
> protocols) a response, by defi= nition, something that a request waits on.
> Once it occurs the reque= st is considered completed.=C2=A0 jsonrpc.el has two
> ways to model = this: jsonrpc-request, blocking and jsonrpc-async-request,
> a non-bl= ocking.
>=C2=A0
> The remote endpoint can send mor= e notifications after responding.=C2=A0 Or
> the client can trigger m= ore requests after it get its first response.

Thanks. The con= text is that I'm trying to see what I need to change to use your librar= y.
I have code in which the server responds with progress information as= it processes a query.=C2=A0 For example

-> (id=3Dxyz) Compute \p= i to 15 decimals
<- (id=3Dxyz, progress) 10% done
<- (id=3Dxyz,= progress) 60% done
<- (id=3Dxyz, response) 3.141592653589793

= The same lambda gets invoked three times, twice with 'progress and a me= ssage, and once with 'done and a number.
Is there a way to model thi= s is json-rpc.el?
=C2=A0
Hmm, I see.=C2=A0 No the library doesn't allo= w this (and neither does
JSONRPC, I think)

There's two ways you can do this (in pseudocode)

(require 'cl-lib)

(let (retval
=C2=A0 =C2=A0 =C2=A0 (calculation-id (symbol-name (gensym))))
= =C2=A0 (while
=C2=A0 =C2=A0 =C2=A0 (cl-destructuring-bind (&k= ey progress result)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (jsonrpc-r= equest conn
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:comp= ute-pi `(:id ,calculation-id :decimals 15))
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 (setq retval result)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (and prog= ress (message "%s" progress)))))

This wo= uld make n requests and n responses and the request handler on
th= e other side must find the calculation id.

The oth= er way would be much simpler and much more JSONRPC'esque would be
=
to issue notifications while the client is waiting for the answer:

=C2=A0 =C2=A0(jsonrpc-request conn :compuate-pi `(:de= cimals 15))

This blocks until the final response i= s gotten, but you get to handle
the progress notifications in a s= eparate notification handler.=C2=A0 Is there
some ambiguous situa= tion where you would not be able to to correlate
them to the requ= est?

Why don't you tell me, in pseudo-code, ho= w you would like it to work?
Perhaps we can add that as a JSONRPC= extension (there's a version=C2=A0
that I'm not using).<= /div>


Jo=C3=A3o
--000000000000df75f3056e5ec366--