Re: jsonrpc.el closer to merging

["Clément Pit-Claudel" <cpitclaudel@gmail.com>]

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.

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.

Btw, there are some discussions on how to do this online, like https://groups.google.com/forum/#!topic/json-rpc/IqDOByU0U0Y, https://groups.google.com/forum/#!msg/json-rpc/5PcrYSfzavA/cLW5buMC48EJ, and https://groups.google.com/forum/#!msg/json-rpc/EWnUwcTmOjY/x-1_beeIJPoJ

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 :) 

Clément.