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: Wed, 13 Jun 2018 11:19:54 +0100 [thread overview]
Message-ID: <87r2lb3s51.fsf@gmail.com> (raw)
In-Reply-To: <521c474b-e36b-d023-80ed-65c735fdd684@gmail.com> ("Clément Pit-Claudel"'s message of "Mon, 11 Jun 2018 19:13:00 -0400")
Clément Pit-Claudel <cpitclaudel@gmail.com> writes:
> On 2018-06-11 18:26, João Távora wrote:
>> In this extension, responses can have a :PARTIAL field, and the endpoint
>> receiving such a request should expect more responses with that ID until
>> a final response with the regular :RESULT field comes in.
>>
>> What do you think?
>
> I think this looks great! And I love that your patch to implement this
> is quite small and understandable.
>
> But I'm also wary of adding extensions to a neat & lean library like
> json-rpc without a rock-solid use case (and I don't think my own
> packages provide a solid enough use-case). I'd be especially worried
> to introduce extensions like this for fear that a future version of
> JSON-RPC might go in a different direction.
It was just a proof of concept and it's backward compatible, but
basically you're right: I better not focus here.
> Given that the patch is fairly simple, how tricky do you think it
> would be to refactor json-rpc slightly to make it possible for clients
> of the library to implement such an extension? I haven't looked at
> the code enough to know how it would be done, but I think it would be
> the best of both worlds: json-rpc remains small and with well-defined
> scpoe, but we add enough knobs to allow clients to reuse its
> foundations while implementing a slightly more complex protocol.
> I guess what I'm saying here is that there's a callback-tracking core
> in json-rpc that's useful even for protocols that are not exactly
> json-rpc; managing to expose it in a sufficiently flexible way (to
> allow building vanilla json-rpc and closely related protocols on top
> of it) would be wonderful, and maybe not too hard since the patch to
> add the particular extension I mentioned seems to have been quite
> small :)
I agree. As you know, there are also downsides to opening "too much"
API (as in you have to maintain it) and the code might become much more
convoluted than adding a single extension, though the advantages of
having something programmable should eventually surpass that.
It shouldn't be terribly hard to do. In jsonrpc.el, the hairiest part
is jsonrpc-connection-receive and jsonrpc-connection-send, where the
:partial keyword arg needs to be passed to the function, which has a
destructuring lambda list that would currently forbid it (since it falls
outside JSONRPC) That needs to be changed in such a way that without the
extension it is still forbidden, but with it, it isn't. Also, in
jsonrpc-connection-receive, the last part (where the continuation is
called) would have to be customizable by hook of by generic function.
Finally, in your extension pacakge just add a custom
my-jsonrpc-partial-accepting-request helper that calls
jsonrpc-async-request with a 2-parameter modified callback lambda.
So, since you seem to have grasped the gist of the code, send me a patch
for something like this :)
João
next prev parent reply other threads:[~2018-06-13 10:19 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
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 [this message]
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=87r2lb3s51.fsf@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.