bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 19 May 2013 12:45:12 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 14380@debbugs.gnu.org, emacs-devel@gnu.org
> 
> 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
    built-in".

  . 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
    begin with.

  . 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??