[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on
bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32
Sun, 19 May 2013 18:44:02 +0300
> From: João Távora <address@hidden>
> Date: Sun, 19 May 2013 12:45:12 +0100
> Cc: Eli Zaretskii <address@hidden>, address@hidden, address@hidden
> The fix I proposed aims for the status quo, that is: make external
> TLS binary support slightly more robust.
I already said at lest twice in this thread: THIS WON'T WORK on
Windows (except in Cygwin Emacs). The communications between the
external TLS client and Emacs are via signals, which aren't really
supported by Windows. Solving this was one of the main reasons for
incorporating GnuTLS into Emacs.
I don't really understand what are we still discussing here. Let me
describe how the current situation looks from my POV:
. Emacs can be built with GnuTLS support if GnuTLS is installed on
the end-user's machine, and that end user builds her own Emacs.
This is the same as on Unix. I hope no one will say this is "not
. Windows users get special treatment in that precompiled binaries
of Emacs are available for those who cannot or won't build their
own. These precompiled binaries are built with GnuTLS support to
. As yet another bonus for Windows users, Emacs will happily start
and run even if GnuTLS is not found on the end-user's machine;
however, TLS will not be available in that case, of course (Emacs
will announce that if required to use TLS).
So now you tell me how come these two bonuses are somehow regarded as
deficiencies? Would it be better not to produce binaries at all, or
let them abort with a fatal error if GnuTLS is not installed?
Installing GnuTLS boils down to unzipping a single zip archive. How
hard can that be for someone who uses Emacs??
bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32, Eli Zaretskii, 2013/05/19