Re: open-{gnutls,network}-stream backwards compatibility

[Robert Pluim]

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