/pidgin/main: e6c37a5e6666: New dependency: libcurl

[Ethan Blanton]

Daniel Atallah spake unto us the following wisdom:
> I don't have much to add about the API conversation apart from the
> comment about how it needs to fit in with the network code within
> libpurple. We shouldn't have the HTTP library doing DNS lookups,
> making its own connections, handling SSL certificates and and etc
> itself - it needs to all go through the libpurple code.  This may mean
> that we need to have our own API wrapping layer.

I agree with this.

I don't know what the libcurl API allows or does not allow, but in my
mind the ideal interface is:

1) libpurple sets up libcurl to use its proxy functions and event loop
2) libpurple handles certificate verification and SSL via the
   libpurple SSL plugins
3) We provide libpurple wrappers for simple http GET and such, similar
   to the existing libpurple http functions (and possibly just the
   existing functions changed to use libcurl)
4) For more complex use cases, users access the libcurl API directly
   -- an API with which they may even already be familiar -- so that
   we don't have to wrap the whole world

The ability to set things up like that requires the libcurl API
creators to have been quite forward-looking.  I think it's the best of
all worlds, however.

(Note that I don't actually care if it's libcurl or libsoup or
 libwhatever; libcurl seems reasonable to me in that *everything* has
 it and Tomasz has already put forth some effort to wrap it.  If there
 is a solid argument for abstracting the http library used by
 libpurple I'd like to hear it, but I'm not really a fan of making it
 pluggable Just Because.)

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/20121001/15fa7e25/attachment.sig>