* bug#72941: jsonrpc: Check if parameters are in line with the spec
@ 2024-09-01 16:26 Felician Nemeth
2024-09-02 11:26 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Felician Nemeth @ 2024-09-01 16:26 UTC (permalink / raw)
To: 72941; +Cc: Daniel Pettersson
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>)
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#72941: jsonrpc: Check if parameters are in line with the spec
2024-09-01 16:26 bug#72941: jsonrpc: Check if parameters are in line with the spec Felician Nemeth
@ 2024-09-02 11:26 ` Eli Zaretskii
2024-09-05 20:35 ` Daniel Pettersson
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2024-09-02 11:26 UTC (permalink / raw)
To: Felician Nemeth, João Távora; +Cc: daniel, 72941
> Cc: Daniel Pettersson <daniel@dpettersson.net>
> From: Felician Nemeth <nemethf@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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#72941: jsonrpc: Check if parameters are in line with the spec
2024-09-02 11:26 ` Eli Zaretskii
@ 2024-09-05 20:35 ` Daniel Pettersson
2024-09-13 17:13 ` Felician Nemeth
0 siblings, 1 reply; 8+ messages in thread
From: Daniel Pettersson @ 2024-09-05 20:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Felician Nemeth, 72941, João Távora
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#72941: jsonrpc: Check if parameters are in line with the spec
2024-09-05 20:35 ` Daniel Pettersson
@ 2024-09-13 17:13 ` Felician Nemeth
2024-09-28 8:47 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Felician Nemeth @ 2024-09-13 17:13 UTC (permalink / raw)
To: Daniel Pettersson; +Cc: Eli Zaretskii, João Távora, 72941
>>> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#72941: jsonrpc: Check if parameters are in line with the spec
2024-09-13 17:13 ` Felician Nemeth
@ 2024-09-28 8:47 ` Eli Zaretskii
2024-09-28 11:40 ` Daniel Pettersson
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2024-09-28 8:47 UTC (permalink / raw)
To: Felician Nemeth; +Cc: daniel, 72941, joaotavora
So do we want to close this as wontfix?
> From: Felician Nemeth <nemethf@tmit.bme.hu>
> Cc: Eli Zaretskii <eliz@gnu.org>,
> João Távora
> <joaotavora@gmail.com>,
> 72941@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.
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#72941: jsonrpc: Check if parameters are in line with the spec
2024-09-28 8:47 ` Eli Zaretskii
@ 2024-09-28 11:40 ` Daniel Pettersson
2024-10-02 11:41 ` Felician Nemeth
2024-10-12 11:21 ` Eli Zaretskii
0 siblings, 2 replies; 8+ messages in thread
From: Daniel Pettersson @ 2024-09-28 11:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Felician Nemeth, 72941, joaotavora
Eli Zaretskii <eliz@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@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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#72941: jsonrpc: Check if parameters are in line with the spec
2024-09-28 11:40 ` Daniel Pettersson
@ 2024-10-02 11:41 ` Felician Nemeth
2024-10-12 11:21 ` Eli Zaretskii
1 sibling, 0 replies; 8+ messages in thread
From: Felician Nemeth @ 2024-10-02 11:41 UTC (permalink / raw)
To: Daniel Pettersson; +Cc: Eli Zaretskii, joaotavora, 72941
Daniel Pettersson <daniel@dpettersson.net> writes:
> Eli Zaretskii <eliz@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@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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#72941: jsonrpc: Check if parameters are in line with the spec
2024-09-28 11:40 ` Daniel Pettersson
2024-10-02 11:41 ` Felician Nemeth
@ 2024-10-12 11:21 ` Eli Zaretskii
1 sibling, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2024-10-12 11:21 UTC (permalink / raw)
To: Daniel Pettersson; +Cc: nemethf, 72941-done, joaotavora
> From: Daniel Pettersson <daniel@dpettersson.net>
> Cc: Felician Nemeth <nemethf@tmit.bme.hu>, joaotavora@gmail.com,
> 72941@debbugs.gnu.org
> Date: Sat, 28 Sep 2024 13:40:00 +0200
>
> Eli Zaretskii <eliz@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@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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-10-12 11:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-01 16:26 bug#72941: jsonrpc: Check if parameters are in line with the spec Felician Nemeth
2024-09-02 11:26 ` Eli Zaretskii
2024-09-05 20:35 ` Daniel Pettersson
2024-09-13 17:13 ` Felician Nemeth
2024-09-28 8:47 ` Eli Zaretskii
2024-09-28 11:40 ` Daniel Pettersson
2024-10-02 11:41 ` Felician Nemeth
2024-10-12 11:21 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).