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 maintained ~150 LOC, BSD-3-clause-licensed, > implementation: > > https://github.com/ncm/selectable-socketpair > > That license is GPL compatible, so should we consider including that > implementation with git? That's the kind of stuff that goes to > compat/win32, right?
Thanks for researching. Sticking that in compat/ would be our usual strategy, yes. > > 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 case (allowing to drop only the > OpenSSL specific stuff), see my other email: > http://www.mail-archive.com/git@vger.kernel.org/msg56791.html (the > relevant part is pretty far down at the bottom). I'd really love it if we could make this work with tunnels and eventually get rid of the hand-written imap code entirely. I agree with Jonathan that we probably need to keep it around a bit for people on older curl, but dropping it is a good goal in the long run. That code was forked from the isync project, but mangled enough that we could not take bug fixes from upstream. As not many people use imap-send, I suspect it is largely unmaintained and the source of many lurking bugs[1]. Replacing it with curl's maintained implementation is probably a good step. -Peff [1] That's my somewhat subjective opinion, but I feel like I have seen several bugs reported in imap-send that had literally been there for years. And having worked on IMAP implementations in a past life, I know there are many dark corners of the protocol that vary from server to server. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
