/pidgin/main: e6c37a5e6666: New dependency: libcurl

[Eion Robb]

> We need to set headers, control
> http version, control content types, send post data, handle redirects,
> proxies, https, authentication, etc.  That's a lot of functionality to
> wrap, so our wrapper functions would be extensive.  Would they closely
> mimic the libcurl API?  If so it might be difficult to swap out
> libcurl for something else.  If not then we'd have to spend time
> figuring out a good abstraction, which would be difficult and allow
> for the possibility of bugs.

I'm not sure I agree.  Things like XMLHttpRequest in JavaScript make
the exposed API simple for devs.  Would you need more than set request
headers, get response headers, get response data, set post data, set
url, set callback func?  Possibly get/set cookies, but that could be
handled from the get/set request/response headers.  Ditto for auth.
Within the wrapper funcs you'd want to just pass in any proxies that
have been set based on the PurpleAccount (or global settings).
libcurl or libsoup would handle https themselves wouldn't they?
IMO: I think that wrapping the HTTP library would provide a lot of
power and strength and flexibility to libpurple.


On 30 September 2012 20:52, Mark Doliner <mark at kingant.net> wrote:
> On Fri, Sep 28, 2012 at 8:18 AM, Elliott Sales de Andrade
> <qulogic at pidgin.im> wrote:
>> On Fri, Sep 28, 2012 at 4:31 AM, Tomasz Wasilczyk
>> <tomkiewicz.groups at gmail.com> wrote:
>>>>> New dependency: libcurl
>>
>> When did we decide to use libcurl over libsoup?
>
> I'm definitely in favor of using a 3rd party http library.  These two
> seem like the best candidates (but if anyone knows of another good
> one, feel free to suggest it).  I've never been a fan of libcurl's
> API.  I haven't used libsoup--maybe it's no better.
>
> Are we sure we can use libcurl on Windows without too much work?
>
>>>> Adding libcurl, do we want to rework our HTTP utility functions to
>>>> simply wrap libcurl?  They could automatically become more robust, but I
>>>> am curious whether we care.
>>>
>>> I think so. But at first, I plan to write curl-specific wrapper:
>>> functions like purple_curl_* to initialize curl handler (tie into
>>> purple event loop), watch it and so on.
>>
>> If we're still going to have our HTTP functions, then I don't see why
>> this needs to exist (publically). That's just an artificial API
>> dependency.
>
> I'm worried about adding a wrapper layer on top of an http library
> (especially if it's libcurl).  http libraries are pretty complicated,
> and we need a lot of functionality.  We need to set headers, control
> http version, control content types, send post data, handle redirects,
> proxies, https, authentication, etc.  That's a lot of functionality to
> wrap, so our wrapper functions would be extensive.  Would they closely
> mimic the libcurl API?  If so it might be difficult to swap out
> libcurl for something else.  If not then we'd have to spend time
> figuring out a good abstraction, which would be difficult and allow
> for the possibility of bugs.
>
> I think if we choose the library wisely then we can use the same http
> library for a long time and we won't need to swap it out, and so we
> don't gain a lot from an abstraction.  Another benefit of using
> libcurl (or whatever) directly is that some people will already be
> familiar with it, it's well documented, you can search for "how do I
> ____ with libcurl?" etc.
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel