From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: jsonrpc.el closer to merging Date: Mon, 11 Jun 2018 19:13:00 -0400 Message-ID: <521c474b-e36b-d023-80ed-65c735fdd684@gmail.com> References: <87sh5uvdnr.fsf@gmail.com> <87k1r6uv3p.fsf@gmail.com> <6733499b-b27f-0886-2e8d-bb59c59ace74@gmail.com> <874li9559h.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1528758667 32196 195.159.176.226 (11 Jun 2018 23:11:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 11 Jun 2018 23:11:07 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Cc: emacs-devel To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 12 01:11:02 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fSVxm-0008IE-Gt for ged-emacs-devel@m.gmane.org; Tue, 12 Jun 2018 01:11:02 +0200 Original-Received: from localhost ([::1]:51797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSVzt-0002c0-OX for ged-emacs-devel@m.gmane.org; Mon, 11 Jun 2018 19:13:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSVzj-0002bd-Vk for emacs-devel@gnu.org; Mon, 11 Jun 2018 19:13:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fSVzi-0000mY-Sn for emacs-devel@gnu.org; Mon, 11 Jun 2018 19:13:03 -0400 Original-Received: from mail-qk0-x236.google.com ([2607:f8b0:400d:c09::236]:45726) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fSVzi-0000mB-OC for emacs-devel@gnu.org; Mon, 11 Jun 2018 19:13:02 -0400 Original-Received: by mail-qk0-x236.google.com with SMTP id c198-v6so13988404qkg.12 for ; Mon, 11 Jun 2018 16:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WNL5VqSUZ3f6fVc8XIuEcHd81/GvwnlJf95sw6ZMDdY=; b=UIrdMATuy+p/wTTwo18zMab6h3+zTlomlR2XeJwl5hL3nU2Vf+U7DTxHO/7Nw91odX 2r5jWvJVzsBkrDOTyJwsCD6N7/nP8SE/+GMJ1vyiiXAmFW1Rw6vYUBpzwXAHjyN3h5zn FZ0LTSEJ9t4u8/enshQJ7ADWCaRi5yUQyqV6ewRh6/R0e41gy2lhiFJve6k2/S1skge9 8HymHTiwWG9smTCY7IumoW2kV6sHsrBsUely9yJHOuldX7M5qfGneqxGFpfNNyeRqL9o bICx9mUjGlPRdybqwhEUWjy8gbJB72UNGX1/aVMjP+VX3werS5dxiqUPESj/g1mXAVAP FPfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WNL5VqSUZ3f6fVc8XIuEcHd81/GvwnlJf95sw6ZMDdY=; b=PiFk2NEYpBIoDAKa0ffYa+0JDG1wKcqvuKJz5HjrESnHeQiTiXnwlWOLclzIG4cG3R TQRhwah5nqm1uAVTUVItjy2Hd7h5ev8qu963vLzOBtGbRdrXXkA2V6Bj4xPRbv9b3gKr dtvV3lBvcYD7P7rqSg0kscHQGXGkiIMVnVmxLjs58RxAi8RkfwWS+gS/hqP9Z8p7HTCv TZNuYYaePPwP6cPmXIK47gST5DbdcfGoG6wxNHBxy+Hx+0Ecwg06aSwMA5l+hIgFN+Nm xR6MyCj+CVeYA0k5by2f4B7E7IvBOXTwsoOHbu5sxzmxvCvX8OF5fu2tNuiMZqGHgd4G 8Msg== X-Gm-Message-State: APt69E1WEN7oQhyMMVC1X57TtpukVKl00KqupCbQthC/wKmXTfReUNVR pkBjv6MNGlW/w6sRrzdvxxiPnFHG X-Google-Smtp-Source: ADUXVKLYJlMMb8Mnth2ALj2RJgmkq3jTp8QvsPH9JzRxd1NPaXE6CquTSRXiV1qzII8liIcZ7EyUQw== X-Received: by 2002:ae9:e8c2:: with SMTP id a185-v6mr1131845qkg.223.1528758782075; Mon, 11 Jun 2018 16:13:02 -0700 (PDT) Original-Received: from ?IPv6:2601:184:4180:66e7:543d:e155:4a97:f2c9? ([2601:184:4180:66e7:543d:e155:4a97:f2c9]) by smtp.gmail.com with ESMTPSA id g49-v6sm21119551qtc.3.2018.06.11.16.13.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 16:13:01 -0700 (PDT) In-Reply-To: <874li9559h.fsf@gmail.com> Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:226241 Archived-At: 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.