Re: [PATCH] GnuTLS support on Woe32

[Stefan Monnier]

> Because of the way SSL and TLS work, the connection may start out
> unencrypted and the upgrade is sort of opportunistic.  So we don't know
> in advance if we'll need the `gnutls-hostname'.

I must be missing something: the code seems to read `gnutls-hostname'
right after reading the keyword arguments, so it behaves just like
a keyword argument AFAICT.  And the caller of gnutls-boot seems to set
it just before calling gnutls-negotiate/gnutls-boot so it seems that
from the caller's POV it could also be replaced by an additional
argument to gnutls-boot/negotiate.

> Also the `gnutls-hostname' is not necessarily the actual host we
> connect to, so we can't keep it as a per-process property.

I don't see how the "so" above connects the two parts of the sentence.
Then again, I still don't know what `gnutls-hostname' stands for so I'm
largely talking about something I don't understand.

> And finally, making it a keyword parameter means the piece that
> *upgrades* the connection to TLS has to know the original hostname of
> the connection.  I thought it was cleaner to separate them, so
> upgrading a connection is easier to do opportunistically.

Sounds reasonable.

> Emacs doesn't have per-process variables at the ELisp level so I had to
> associate it with the buffer and making it buffer-local seemed
> sensible.  How would you do it?

Not sure what you mean.  Don't process-put/get provide per-process
"variables"?  Also, rather than a buffer-local variable, why not use
a let-bound variable instead?

> (there's no `declare-variable').

Of course there is: it's called (defvar <VAR>).

> Sorry this patch is getting so large.  I'll try to fix all the issues
> ASAP.  We need Claudio Bley's papers too, right?

I don't know, I haven't tracked what comes from where.


        Stefan