Re: jsonrpc.el closer to merging

[Clément Pit-Claudel]

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.