/pidgin/main: e6c37a5e6666: New dependency: libcurl

[Eion Robb]

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