/pidgin/main: e6c37a5e6666: New dependency: libcurl

[Tomasz Wasilczyk]

My http implementation [1] now covers all purple_util_fetch_url
features (I event did wrapping inside purple_util_fetch_url, to use
new method). I didn't implemented features requested recently by Eion
Robb, but they are possible to be added there (and maybe I will do it
later).

There are some more features, I am working on (cookies support, or
requests with contents, like POST), but the rest of code seems to be
ready. Could someone look at it before merge (code in gg prpl is only
for debugging, it won't be merged)?

Tomek

[1] http://hg.pidgin.im/cpw/tomkiewicz/http/

2012/10/13 Eion Robb <eion at robbmob.com>:
> Some other good things that I had to implement when writing the HTTP
> code which would be useful to have in the new system would be:
> gzip compression support
> dns caching - since that can be the slowest part of the connection init
> http connection queue so that there's not more than X simultaneous
> connections (libpurple doesn't quite like it if you do 200ish buddy
> icon requests at the same time :) )
> keepalive support (ok, I didn't get to implement this one, but it
> would save on the number of connection init's)
>
>
> On 13 October 2012 15:27, Tomasz Wasilczyk <tomkiewicz.groups at gmail.com> wrote:
>> Implementation in progress at [1].
>>
>> Tomek
>>
>> [1] http://hg.pidgin.im/cpw/tomkiewicz/http/
>>
>> 2012/10/11 Eion Robb <eion at robbmob.com>:
>>> With a new api, can you add a function so that all requests attached
>>> to a particular PurpleConnection be cancelled, eg when an account is
>>> disabled/logs out, eg
>>> void purple_http_conn_cancel_all(PurpleConnection *);
>>> and maybe
>>> GSList purple_http_conn_get_all(PurpleConnection *);
>>>
>>> On 11 October 2012 09:29, Tomasz Wasilczyk <tomkiewicz.groups at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I have prepared proposal for our new HTTP API [1]. It currently
>>>> doesn't support easily handled POST fields - it can be added later,
>>>> without breaking API (just extending it).
>>>>
>>>> It also doesn't support raw requests, because:
>>>> - most of not supported features can be easily emulated by handling of
>>>> parsed http headers
>>>> - if there would be any feature not possible to handle here, we can
>>>> just add such new feature to our API
>>>> - it would be hard (and buggy) to handle such raw requests (for
>>>> example: redirects)
>>>>
>>>> After introducing it, our current HTTP code (purple_util_fetch_url*)
>>>> could be removed from API, marked deprecated and slowly removed from
>>>> libpurple code by replacing with purple_http_get and
>>>> purple_http_request.
>>>>
>>>> Waiting for comments,
>>>> Tomek
>>>>
>>>> [1] http://pastebin.com/QnQHSDsL
>>>>
>>>> 2012/10/8 Tomasz Wasilczyk <tomkiewicz.groups at gmail.com>:
>>>>> I don't think, there is any library that fits better into our requirements.
>>>>> So, if using libcurl with its current limitations is undesirable, I have
>>>>> another proposal. We may create a new, extendable http api, with our
>>>>> implementation. When libcurl (or any other library) will gain required
>>>>> features, we will switch to it.
>>>>>
>>>>> Current API is horrible to use when making more complex requests (it
>>>>> requires manually built requests).
>>>>>
>>>>> Tomek
>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel at pidgin.im
>>>> http://pidgin.im/cgi-bin/mailman/listinfo/devel