Am 2014-08-17 um 20:42 schrieb Jeff King:
[...]
I'm not sure I understand this comment. Even if SSL is not in use,
wouldn't we be passing a regular pipe to curl, which would break?
Yeah, we can't do that, and thus would have to keep the handwritten IMAP
implementation just for the tunnel
Bernhard Reiter ock...@raz.or.at writes:
Am 2014-08-17 um 20:42 schrieb Jeff King:
[...]
I'm not sure I understand this comment. Even if SSL is not in use,
wouldn't we be passing a regular pipe to curl, which would break?
Yeah, we can't do that, and thus would have to keep the handwritten
On Tue, Aug 12, 2014 at 06:59:17PM -0700, Jonathan Nieder wrote:
+ curl_socket_t sockfd = tunnel.out; // what about tunnel.in ?
Hmm. curl expects to get a socket it can send(), recv(), setsockopt(),
etc on instead of a pair of fds to read() and write().
I wonder if we could
Am 2014-08-17 um 10:30 schrieb Jeff King:
On Tue, Aug 12, 2014 at 06:59:17PM -0700, Jonathan Nieder wrote:
+ curl_socket_t sockfd = tunnel.out; // what about tunnel.in ?
Hmm. curl expects to get a socket it can send(), recv(), setsockopt(),
etc on instead of a pair of fds to
On Sun, Aug 17, 2014 at 02:56:10PM +0200, Bernhard Reiter wrote:
I'm not sure if that would cause problems on Windows,
though.
Apparently socketpair is not available there. Googling socketpair
windows yields, among a lot of other useful resources, the following
relatively actively
Use libcurl's high-level API functions to implement git-imap-send
instead of the previous low-level OpenSSL-based functions.
Since version 7.30.0, libcurl's API has been able to communicate with
IMAP servers. Using those high-level functions instead of the current
ones would reduce imap-send.c
Bernhard Reiter wrote:
Use libcurl's high-level API functions to implement git-imap-send
instead of the previous low-level OpenSSL-based functions.
Wow! This sounds lovely. Thanks for working on this.
[...]
Since version 7.30.0, libcurl's API has been able to communicate with
IMAP
7 matches
Mail list logo
