[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: open-{gnutls,network}-stream backwards compatibility
From: |
Robert Pluim |
Subject: |
Re: open-{gnutls,network}-stream backwards compatibility |
Date: |
Wed, 02 Jan 2019 18:47:55 +0100 |
Eli Zaretskii <address@hidden> writes:
>> From: Robert Pluim <address@hidden>
>> Date: Wed, 02 Jan 2019 17:49:13 +0100
>>
>> 1. As part of that fix, Iʼd like to change the signature of
>> open-gnutls-stream from
>>
>> (open-gnutls-stream name buffer host service &optional nowait)
>>
>> to
>>
>> (open-gnutls-stream name buffer host service &optional nowait parameters)
>>
>> 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ʼm tempted to just change it
>> to:
>>
>> (open-gnutls-stream name buffer host service &optional parameters)
>>
>> then adjust the single in-core caller and have open-gnutls-stream
>> call plist-get.
>>
>> 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ʼs not perfect, but I guess backwards compatibility is
important.
>> Again Iʼm 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ʼd 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ʼt think many people have
such entries, and they almost certainly already have workarounds in
place for the current situation.
If we donʼt 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ʼs
those external updates I was hoping to avoid.
Robert
Robert
- open-{gnutls,network}-stream backwards compatibility, Robert Pluim, 2019/01/02
- Re: open-{gnutls,network}-stream backwards compatibility, Eli Zaretskii, 2019/01/02
- Re: open-{gnutls,network}-stream backwards compatibility,
Robert Pluim <=
- Re: open-{gnutls,network}-stream backwards compatibility, Eli Zaretskii, 2019/01/02
- Re: open-{gnutls,network}-stream backwards compatibility, Robert Pluim, 2019/01/02
- Re: open-{gnutls,network}-stream backwards compatibility, Eli Zaretskii, 2019/01/04
- Re: open-{gnutls,network}-stream backwards compatibility, Robert Pluim, 2019/01/04
- Re: open-{gnutls,network}-stream backwards compatibility, Eli Zaretskii, 2019/01/05
- Re: open-{gnutls,network}-stream backwards compatibility, Robert Pluim, 2019/01/05
- Re: open-{gnutls,network}-stream backwards compatibility, Eli Zaretskii, 2019/01/05
- Re: open-{gnutls,network}-stream backwards compatibility, Robert Pluim, 2019/01/09
- Re: open-{gnutls,network}-stream backwards compatibility, Ted Zlatanov, 2019/01/10
- Re: open-{gnutls,network}-stream backwards compatibility, Eli Zaretskii, 2019/01/10