/pidgin/main: e6c37a5e6666: New dependency: libcurl

[Tomasz Wasilczyk]

2012/10/1 Ethan Blanton <elb at pidgin.im>:
> There are a couple of things to watch, here.  First off, requiring
> synchronous connect is bad, because it means libcurl is doing
> synchronous DNS lookup followed by connect(), which can stall the UI.

I'm not sure, how exactly this may lead to such conclusions. Anyway,
I'm pretty sure, that this is just an libcurl API issue (maybe they
didn't figred out, that somebody will need to return a new socket
after a while).

> Can we use *real* sockets here?  I assume the problem is that the open
> socket function has to return a "real" fd in that case, and we don't
> have one...

That's exactly the problem.

>  Once our sockets are open, though, curl can use normal
> read()/write()/etc. on them.  That is, assuming it understands
> SO_NONBLOCK sockets.

I'm not sure, if I understand correctly. Are you suggesting, that we
can return an "empty" fd and - later - swap it with real, opened
socket?

> (..*) this can go into 3.0.0 without problem.  We haven't
> frozen that API.

I meant the situation, in which we figure out, that some new feature
is useful *after* releasing 3.0.0.

Tomek