/pidgin/main: e6c37a5e6666: New dependency: libcurl

Tomasz Wasilczyk tomkiewicz.groups at gmail.com
Sat Sep 29 06:01:10 EDT 2012

2012/9/29 Tomasz Wasilczyk <tomkiewicz.groups at gmail.com>:
> 2012/9/29 Eion Robb <eion at robbmob.com>:
>> I don't thing that purple functions should be specific to curl or lib soup,
>> that it'd be best to wrap it (like we have done for farsight2/far stream and
>> for nss and that other one) so that they can be swapped out as needed.  I
>> would be more in favour of making the current request functions work with
>> optionally either lib soup or curl, specified at compile time.

After reconsidering, I have to admit, you're right. It's undesirable
to have such dependency in API. So, my proposal is to:
- provide purple_http_* API functions (similiar to purple_curl_*, but
without any dependency) to support http in libpurple and its plugins
- provide plugin API, like for ssl, to support multiple http libraries
- get rid of purple_util_fetch_url*, by replacing all uses with new
ones (3.0.0 break)
- implement http support based on libcurl for now (when someone will
need libsoup one, he will write such plugin)

Is it good approach? Can I start completing it?


More information about the Devel mailing list