From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: jsonrpc.el closer to merging Date: Wed, 13 Jun 2018 11:19:54 +0100 Message-ID: <87r2lb3s51.fsf@gmail.com> References: <87sh5uvdnr.fsf@gmail.com> <87k1r6uv3p.fsf@gmail.com> <6733499b-b27f-0886-2e8d-bb59c59ace74@gmail.com> <874li9559h.fsf@gmail.com> <521c474b-e36b-d023-80ed-65c735fdd684@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1528885089 18690 195.159.176.226 (13 Jun 2018 10:18:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 13 Jun 2018 10:18:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 13 12:18:05 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 1fT2qo-0004hp-Af for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2018 12:18:02 +0200 Original-Received: from localhost ([::1]:33041 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fT2sv-0008Ij-9m for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2018 06:20:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fT2sm-0008HM-35 for emacs-devel@gnu.org; Wed, 13 Jun 2018 06:20:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fT2sh-0001S6-W6 for emacs-devel@gnu.org; Wed, 13 Jun 2018 06:20:04 -0400 Original-Received: from mail-wr0-x22f.google.com ([2a00:1450:400c:c0c::22f]:44138) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fT2sh-0001R9-P4 for emacs-devel@gnu.org; Wed, 13 Jun 2018 06:19:59 -0400 Original-Received: by mail-wr0-x22f.google.com with SMTP id x4-v6so2121302wro.11 for ; Wed, 13 Jun 2018 03:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=+NSZhJ4Q5D7tVO+LWtLAGI3E+zoSgsiohiuMk9h0CWo=; b=fxNVH1nU0rSUk/fw7nVbJbdt5XWD7/4HZAf4/JIFXI822aZDSwVkKakm1rA7rUtN8v h/a8rleWdhdEQCGdzekMg3+yC2unlYPPnnyHv5XEuIV/q+8xvoBVtXb1Cm7sHJ4PUnTF VtEb2IMrVVtgyH6MK1taNk6Fzf4NGFDCG7y0WfV6i+CibLjsS5+KvflJMTsQOpY9odNy NMHOZ/DwW5xc/W/v77DRa+kGgRgOMvef/ANzQ6CZh/oDC+Bgx8Zqjo5q7X46uU0LxtJg JGuFvZSJKAZMTbb5Ei15w4S3QjYFtS/V/BjnCgXBNW/M3pA9DoGHQHVQplsN8TrvXGLK WGtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=+NSZhJ4Q5D7tVO+LWtLAGI3E+zoSgsiohiuMk9h0CWo=; b=Gg4zvNfZlxniYur1hGCO+L/ZFXmI0c/XkL116lCg7qYB3xhrvZqttpBuqiy35TQbQg DrTu4b3QDZ7MRgLL5kLHjKHKTHQdK9q38grJnKvPwy9TwfzwW9oceQAcvkkotjy/Net9 A41B9WUcDAN0q6K7VEexNtmqFQ6py64n6N7WtfSyon4gQJ41PM8fFS9TEtt4uNxNfnAK xKTFY2DJmcwtNYb0vqze9g8IZs9WBlivjKsMOZcuiM+65nesjuiH0NqWt6kRkcZ+wnQ0 HYYUXw9bJ9o61CXam5sgvhssMnPs4ReevF7j5SydTc3/DP9PxmHaDPWZUxgseenBhXHa buPw== X-Gm-Message-State: APt69E02+InEa7+64SmBjk+ZGqf4Z+Rlkux4FAaRV0EXFjvQLLi3A0Zp a05gl8Ck/1Yv87l8G90cgZkNtX+K X-Google-Smtp-Source: ADUXVKIQ+7cChc4X6IbxpzvJgooV3MKgcI730jQZAyyVL4kfPa0rrTfi1xFZvQkAzY1qr2cIjUhT0A== X-Received: by 2002:adf:a706:: with SMTP id c6-v6mr3807468wrd.61.1528885198450; Wed, 13 Jun 2018 03:19:58 -0700 (PDT) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id c11-v6sm2362713wrm.65.2018.06.13.03.19.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 13 Jun 2018 03:19:57 -0700 (PDT) In-Reply-To: <521c474b-e36b-d023-80ed-65c735fdd684@gmail.com> (=?utf-8?Q?=22Cl=C3=A9ment?= Pit-Claudel"'s message of "Mon, 11 Jun 2018 19:13:00 -0400") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::22f 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:226284 Archived-At: Cl=C3=A9ment Pit-Claudel writes: > On 2018-06-11 18:26, Jo=C3=A3o T=C3=A1vora 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. >>=20 >> 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=C3=A3o