GNU bug report logs - #72941
jsonrpc: Check if parameters are in line with the spec

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72941 in the body.
You can then email your comments to 72941 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <nemethf <at> tmit.bme.hu>
To: bug-gnu-emacs <at> gnu.org
Subject: jsonrpc: Check if parameters are in line with the spec
Date: Sun, 01 Sep 2024 18:26:02 +0200

I failed to implement an LSP extension to Eglot, because my function
sent a required parameter as a string instead of an array containing a
single element: the string.  In the end it turned out that this was my
fault, because according to the JSON specification: "If present,
parameters for the rpc call MUST be provided as a Structured
value. Either by-position through an Array or by-name through an
Object."  https://www.jsonrpc.org/specification#parameter_structures

Would it be possible to extend jsonrpc.el to check the params argument
of jsonrpc-request, jsonrpc-notify, and jsonrpc-async-request whether it
is a structured value?  And if it is not, then guide the programmer to
the above URL with a warning.

Thank you.

(Background: <https://github.com/ocaml/ocaml-lsp/issues/1330>)

Message #8 received at 72941 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Felician Nemeth <nemethf <at> tmit.bme.hu>, João Távora
 <joaotavora <at> gmail.com>
Cc: daniel <at> dpettersson.net, 72941 <at> debbugs.gnu.org
Subject: Re: bug#72941: jsonrpc: Check if parameters are in line with the spec
Date: Mon, 02 Sep 2024 14:26:22 +0300

> Cc: Daniel Pettersson <daniel <at> dpettersson.net>
> From: Felician Nemeth <nemethf <at> tmit.bme.hu>
> Date: Sun, 01 Sep 2024 18:26:02 +0200
> 
> I failed to implement an LSP extension to Eglot, because my function
> sent a required parameter as a string instead of an array containing a
> single element: the string.  In the end it turned out that this was my
> fault, because according to the JSON specification: "If present,
> parameters for the rpc call MUST be provided as a Structured
> value. Either by-position through an Array or by-name through an
> Object."  https://www.jsonrpc.org/specification#parameter_structures
> 
> Would it be possible to extend jsonrpc.el to check the params argument
> of jsonrpc-request, jsonrpc-notify, and jsonrpc-async-request whether it
> is a structured value?  And if it is not, then guide the programmer to
> the above URL with a warning.
> 
> Thank you.
> 
> (Background: <https://github.com/ocaml/ocaml-lsp/issues/1330>)

Adding João.

Message #11 received at 72941 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Pettersson <daniel <at> dpettersson.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Felician Nemeth <nemethf <at> tmit.bme.hu>, 72941 <at> debbugs.gnu.org,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#72941: jsonrpc: Check if parameters are in line with the spec
Date: Thu, 05 Sep 2024 22:35:32 +0200

>> Would it be possible to extend jsonrpc.el to check the params argument
>> of jsonrpc-request, jsonrpc-notify, and jsonrpc-async-request whether it
>> is a structured value?  And if it is not, then guide the programmer to
>> the above URL with a warning.

The use case makes sense to me, but I would go with updating the docs
rather then the API.  The current wording could use some love as it's
refereed to as JSON object or plist (at different functions).  When it
should be plist or vector, where we could throw in a link to the
specification.

I am not for signaling an error or similar as it's a breaking change in
my book, which does not seam called for in this case.

/Daniel Pettersson

Message #14 received at 72941 <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <nemethf <at> tmit.bme.hu>
To: Daniel Pettersson <daniel <at> dpettersson.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 João Távora <joaotavora <at> gmail.com>, 72941 <at> debbugs.gnu.org
Subject: Re: bug#72941: jsonrpc: Check if parameters are in line with the spec
Date: Fri, 13 Sep 2024 19:13:16 +0200

>>> Would it be possible to extend jsonrpc.el to check the params argument
>>> of jsonrpc-request, jsonrpc-notify, and jsonrpc-async-request whether it
>>> is a structured value?  And if it is not, then guide the programmer to
>>> the above URL with a warning.
>
> The use case makes sense to me, but I would go with updating the docs
> rather then the API.  The current wording could use some love as it's
> refereed to as JSON object or plist (at different functions).  When it
> should be plist or vector, where we could throw in a link to the
> specification.

Makes sense.

> I am not for signaling an error or similar as it's a breaking change in
> my book, which does not seam called for in this case.

Maybe when the server responds with an error to a jsonrpc-request, then
jsonrpc.el could create an additional warning if the params of the
request was not structured.  Or maybe it is too much work for a very
small gain.

Thank you.

Message #17 received at 72941 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Felician Nemeth <nemethf <at> tmit.bme.hu>
Cc: daniel <at> dpettersson.net, 72941 <at> debbugs.gnu.org, joaotavora <at> gmail.com
Subject: Re: bug#72941: jsonrpc: Check if parameters are in line with the spec
Date: Sat, 28 Sep 2024 11:47:13 +0300

So do we want to close this as wontfix?

> From: Felician Nemeth <nemethf <at> tmit.bme.hu>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>         João Távora
>  <joaotavora <at> gmail.com>,
>         72941 <at> debbugs.gnu.org
> Date: Fri, 13 Sep 2024 19:13:16 +0200
> 
> >>> Would it be possible to extend jsonrpc.el to check the params argument
> >>> of jsonrpc-request, jsonrpc-notify, and jsonrpc-async-request whether it
> >>> is a structured value?  And if it is not, then guide the programmer to
> >>> the above URL with a warning.
> >
> > The use case makes sense to me, but I would go with updating the docs
> > rather then the API.  The current wording could use some love as it's
> > refereed to as JSON object or plist (at different functions).  When it
> > should be plist or vector, where we could throw in a link to the
> > specification.
> 
> Makes sense.
> 
> > I am not for signaling an error or similar as it's a breaking change in
> > my book, which does not seam called for in this case.
> 
> Maybe when the server responds with an error to a jsonrpc-request, then
> jsonrpc.el could create an additional warning if the params of the
> request was not structured.  Or maybe it is too much work for a very
> small gain.
> 
> Thank you.
> 

Message #20 received at 72941 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Pettersson <daniel <at> dpettersson.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Felician Nemeth <nemethf <at> tmit.bme.hu>, 72941 <at> debbugs.gnu.org,
 joaotavora <at> gmail.com
Subject: Re: bug#72941: jsonrpc: Check if parameters are in line with the spec
Date: Sat, 28 Sep 2024 13:40:00 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> So do we want to close this as wontfix?

Yes, if anybody would clarify the variable type expectations
documentation that would be great but all in all this is would be
wontfix.

>> From: Felician Nemeth <nemethf <at> tmit.bme.hu>

>> Maybe when the server responds with an error to a jsonrpc-request, then
>> jsonrpc.el could create an additional warning if the params of the
>> request was not structured.  Or maybe it is too much work for a very
>> small gain.

It seams like something that would be a bit of mess and I would expect
that an sane jsonrpc server would include the reason for error in the
error response.

Message #23 received at 72941 <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <nemethf <at> tmit.bme.hu>
To: Daniel Pettersson <daniel <at> dpettersson.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, joaotavora <at> gmail.com, 72941 <at> debbugs.gnu.org
Subject: Re: bug#72941: jsonrpc: Check if parameters are in line with the spec
Date: Wed, 02 Oct 2024 13:41:06 +0200

Daniel Pettersson <daniel <at> dpettersson.net> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> So do we want to close this as wontfix?
>
> Yes, if anybody would clarify the variable type expectations
> documentation that would be great but all in all this is would be
> wontfix.

I can accept this decision.

>>> From: Felician Nemeth <nemethf <at> tmit.bme.hu>
>
>>> Maybe when the server responds with an error to a jsonrpc-request, then
>>> jsonrpc.el could create an additional warning if the params of the
>>> request was not structured.  Or maybe it is too much work for a very
>>> small gain.
>
> It seams like something that would be a bit of mess and I would expect
> that an sane jsonrpc server would include the reason for error in the
> error response.

The server I used did not return an error message, from which I could
easily understand the real problem.

Thanks.

Message #28 received at 72941-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Pettersson <daniel <at> dpettersson.net>
Cc: nemethf <at> tmit.bme.hu, 72941-done <at> debbugs.gnu.org, joaotavora <at> gmail.com
Subject: Re: bug#72941: jsonrpc: Check if parameters are in line with the spec
Date: Sat, 12 Oct 2024 14:21:42 +0300

> From: Daniel Pettersson <daniel <at> dpettersson.net>
> Cc: Felician Nemeth <nemethf <at> tmit.bme.hu>,  joaotavora <at> gmail.com,
>   72941 <at> debbugs.gnu.org
> Date: Sat, 28 Sep 2024 13:40:00 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > So do we want to close this as wontfix?
> 
> Yes, if anybody would clarify the variable type expectations
> documentation that would be great but all in all this is would be
> wontfix.
> 
> >> From: Felician Nemeth <nemethf <at> tmit.bme.hu>
> 
> >> Maybe when the server responds with an error to a jsonrpc-request, then
> >> jsonrpc.el could create an additional warning if the params of the
> >> request was not structured.  Or maybe it is too much work for a very
> >> small gain.
> 
> It seams like something that would be a bit of mess and I would expect
> that an sane jsonrpc server would include the reason for error in the
> error response.

No further comments, so I'm now closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.