From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.devel Subject: Re: open-{gnutls,network}-stream backwards compatibility Date: Wed, 02 Jan 2019 18:47:55 +0100 Message-ID: References: <831s5v3s9w.fsf@gnu.org> 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 1546451206 10858 195.159.176.226 (2 Jan 2019 17:46:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 Jan 2019 17:46:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 02 18:46:42 2019 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 1gekbK-0002lT-6o for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2019 18:46:42 +0100 Original-Received: from localhost ([127.0.0.1]:46512 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gekdQ-0000rY-P1 for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2019 12:48:52 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gekcZ-0000qP-MH for emacs-devel@gnu.org; Wed, 02 Jan 2019 12:48:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gekcY-0002cm-PE for emacs-devel@gnu.org; Wed, 02 Jan 2019 12:47:59 -0500 Original-Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:36319) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gekcY-0002cN-IR; Wed, 02 Jan 2019 12:47:58 -0500 Original-Received: by mail-wr1-x433.google.com with SMTP id u4so31254603wrp.3; Wed, 02 Jan 2019 09:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:mail-followup-to:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=eXbg4YwO2/b/X++DYnG9IM94Mr81sdMBbDqLTr7IKiI=; b=ASwKQNIxzHDOcO0TGiqNU0kUyVFgYJLDnvlbDEZAs0g0eJ7b0hQktBasdRpSt3y1AJ kgCnIyKkm61FHIPYlynMtz4hidwXP/vnbtWEUv10BM3DI3GRiOqQwI4NGVBwKiXBwqqn VPORCDK2eEGQDdaeXD2PWQeEVXbjCjwxVtehHCgm7gzmefiq0wO6LcWd7TpqfWsJE8ku mqh2WlIVqMw62CxTpZvuKJwI4L5B1TlMSNEhQJ2QDcN6f1np1b65e2aJ5T5HDmqAnJmW BwUFIV60uScM8Z/SKwGzwLCYpZTeAtk74nr0rakvhkuKHCFk/wJmHFcU76lAORPtt4ja GY6g== 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:mail-followup-to :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=eXbg4YwO2/b/X++DYnG9IM94Mr81sdMBbDqLTr7IKiI=; b=q28qYCN4xLGKZSnseUwsq26FpEax1JiV6c64gHSolaKgPu8DSFd7ZJA0GuS2FP2Zrj R5QU27Xwops95nZCsOOWB7MA+0ruckDPKnvV103Sl+T3xt5kruIC22c8rd76aOF1UTwH mm6p9pZ8NMWNRomyhCig+hyGV7nOc7BUWLONF+qldxj+hstT4gwRjQWaKZyjQuwrEqkW EmVZnawFgchK7Tb99O75MiJAWho4MaKtb9+p5S3/0157QGSIlA1jn8iodcrSrarEQL33 rcdgB08GQORHx6vOGeR8c7i6kSSZ6Uah+mPp1z6pPWYuWmTCdFAw8lvilikzWTA7616r dDfA== X-Gm-Message-State: AJcUukcxIgnr/fQpAeTYsmltrthGnJIHz+X4vxeZCgzXOqMo4umHBqVx 0ak1SyY1WXr+YNuvMnNS/2QcuNUN X-Google-Smtp-Source: ALg8bN5aAX6rdM73qpmlCoxYVqZ36ZvYTWpzspJBv9fDHaKM4Wq0FyOjC9j5kuk77LZijaRMZvfOvQ== X-Received: by 2002:a5d:570c:: with SMTP id a12mr19316230wrv.161.1546451276915; Wed, 02 Jan 2019 09:47:56 -0800 (PST) Original-Received: from rpluim-mac ([2a01:e34:ecfc:a860:49e7:b838:816f:540b]) by smtp.gmail.com with ESMTPSA id y12sm32456101wmi.7.2019.01.02.09.47.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 02 Jan 2019 09:47:56 -0800 (PST) Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <831s5v3s9w.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 02 Jan 2019 19:04:27 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::433 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:232095 Archived-At: Eli Zaretskii writes: >> From: Robert Pluim >> Date: Wed, 02 Jan 2019 17:49:13 +0100 >>=20 >> 1. As part of that fix, I=CA=BCd like to change the signature of >> open-gnutls-stream from >>=20 >> (open-gnutls-stream name buffer host service &optional nowait) >>=20 >> to >>=20 >> (open-gnutls-stream name buffer host service &optional nowait parame= ters) >>=20 >> Normally this would be fine, I think, except that the caller in >> Emacs core derives the value of 'nowait' from the plist that would be >> passed in via 'parameters' anyway, so I=CA=BCm tempted to just chang= e it >> to: >>=20 >> (open-gnutls-stream name buffer host service &optional parameters) >>=20 >> then adjust the single in-core caller and have open-gnutls-stream >> call plist-get. >>=20 >> Does anyone see any issue with doing this? > > How about changing the code so that PARAMETERS could also be a symbol, > in which case it would be interpreted in backward-compatible way? You mean like in my footnote 2? :-) So nil/t would mean :nowait nil/t, and anything else would be a plist. It=CA=BCs not perfect, but I guess backwards compatibility is important. >> Again I=CA=BCm tempted to change open-network-stream such that not >> specifying :client-certificate is the same as specifying t, so >> that all Emacs core and external packages can take advantage of >> the feature just by adjusting their .authinfo entries, similarly >> to how password lookup automatically works today. However, this >> would be a change in default behaviour, plus I know some people >> are very sensitive to changes in this particular area, so I >> thought I=CA=BCd ask here before doing anything. > > IMO, we should resist the temptation of making backward-incompatible > changes. From bitter experience, even obscure internal functions are > sometimes used, and their users don't expect us to break the APIs. That applies to open-gnutls-stream, but I was asking about open-network-stream. For people who have no client certificate entries in their auth-source, there would be zero difference. Judging by the lack of documentation in this area, I don=CA=BCt think many people have such entries, and they almost certainly already have workarounds in place for the current situation. If we don=CA=BCt change open-network-stream, then I was planning on changing all callers in Emacs to use :client-certificate t in any case, so only external users of open-network-stream would need to update their code to enable automatic use of client certificates. It=CA=BCs those external updates I was hoping to avoid. Robert Robert