/pidgin/main: e6c37a5e6666: New dependency: libcurl

[Ethan Blanton]

Tomasz Wasilczyk spake unto us the following wisdom:
> 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).

I just looked at the curl code, and you're right, they do use async
lookups *internally*.  However, it limits us to sync lookups using
their external UI.  Either way, not good.

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

OK.

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

No, I don't think we can do that, but we may be able to provide an
actual socket.  I was thinking out loud.  I'm pretty sure we'll have
to provide a buffering abstraction to allow for curl to call open and
then write immediately, since it may think it can do that -- and even
if it doesn't *currently* think it can do that, unless their API shows
us that it never will, we'll have to buffer.

If the API actually understands a socket that's not ready, we may be
able to call socket(), save the socket someplace, call connect()
nonblocking, and hand the saved socket directly to curl.  It won't be
writeable/readable/whatever until connect() succeeds or fails.  I'd
have to look at the API they offer to see how reasonable this is.

> > (..*) 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.

OK.

Ethan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20121002/7872dd80/attachment.sig>