emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] GnuTLS support on Woe32


From: Claudio Bley
Subject: Re: [PATCH] GnuTLS support on Woe32
Date: Wed, 09 Mar 2011 22:26:01 +0100
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.8 Emacs/23.1 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

At Mon, 07 Mar 2011 21:26:57 -0600,
Ted Zlatanov wrote:
> 
> [1  <text/plain (7bit)>]
> On Sun, 06 Mar 2011 16:16:34 +0100 address@hidden (Claudio Bley) wrote: 
> 
> CB> Please find attached a patch which makes building Emacs with GnuTLS
> CB> support on Woe32 possible.
> 
> Claudio, thanks so much for looking at this.  My C is very rusty and I
> appreciate all your help.  I also don't know GnuTLS very well so your
> insight is very good.

Thank you so much for your encouraging words, but I thought you would
be the expert in GnuTLS + Emacs business.. :)

> I'll comment and at the end will show my own work on verification and
> callbacks.  Whatever I don't comment, assume it's excellent :)  I hope
> you can take what I've done, which is much less capable than your patch,
> and bring it into yours to improve the GnuTLS support on all platforms.

I'll take a look at your patch when I find the time.

> CB> +2011-03-06  Claudio Bley  <address@hidden>
> CB> +
> CB> + * starttls.el (starttls-negotiate-gnutls, starttls-open-stream-gnutls):
> CB> + Check for builtin GnuTLS support and use it if available.
> CB> +
> 
> I think this should be optional.  GnuTLS locks up Emacs hard with
> concurrent connections (see Lars' email about that from earlier this
> week on emacs-devel).  Also I intentionally made gnutls.el a separate
> file to avoid overriding starttls.el.  It shouldn't just take over the
> starttls.el functionality.  There are too many parameters and no way to
> tune them right now; starttls.el is not tunable at all.
> But it's good to have a way to just swap all the starttls.el
> functionality for gnutls.el functionality, for testing and for brave
> users, so I'm OK with making it optional.

Having thought about that twice I second that. I'll probably write
some defadvice to that matter.

- Claudio





reply via email to

[Prev in Thread] Current Thread [Next in Thread]