[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: jsonrpc.el closer to merging
From: |
João Távora |
Subject: |
Re: jsonrpc.el closer to merging |
Date: |
Wed, 13 Jun 2018 11:19:54 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Clément Pit-Claudel <address@hidden> 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
Re: jsonrpc.el closer to merging, Stefan Monnier, 2018/06/10