Что выбрать для работы с http ?

Кроме Qt ничего предложить не могу, да и многие здесь скажут, что это один из лучших вариантов :)

толстый, и хрен соберешь куда мне надо :)
Как Борис хрен попадешь :)

почему не привязываться к пуре си библиотекам? для начала glib + libsoup

я не враг своему здоровью, у меня кроме передачи данных ещё и логика есть:) Да и смешивать стайлы не комильфо.

SOAP не нужен, прошу прощения если слова про веб службы ввели кого то в заблуждение.

Идеальное решение это cpp-netlib, который соберется без патчей и бубнов на gcc 3.6 и ядре 2.6.15(если это имеет значение).

SOAP не нужен, прошу прощения если слова про веб службы ввели кого то в заблуждение.

***

libsoup

Походу пора спать :)

cpp-netlib - свои велосипеды навалены в одну кучу. зависит от буста. это не юникс. посылаю вам лучик поноса по этому поводу =). я думаю libcurl - правильный выбор

Тогда libcurl, если интересуют плюсы - POCO либо обёртки над libcurl.

cpp-netlib - свои велосипеды навалены в одну кучу. зависит от буста.

В C++ до tr1 даже shared_ptr нету. Буст даёт кучу вещей, необходимых для написания удобной библиотечки в C++98. Так что пусть люди либо пользуются boost, либо используют C++ 2011 вместо старья, либо не жалуются что под их экстримальные условия нет ничего готового.

Некоторым заказчикам дай волю, так они попросят фотошоп для холодильника написать, причём на холодильник дадут только спецификации вместо собственно холодильника, и то не все. Поделом этим ССЗБ.

а если таки получить холодильник выяснится, что в стоковой оси половина драйверов не работают и ось не обновляется по причине некромантии

На comp.unix.progammer советовали http://lacewing-project.org/

А самому наваять на boost::asio не вариант? Я так и сделал после того как evhttp из libevent окончательно затрахал.

я думаю libcurl - правильный выбор

Там же страшный API, потоки и еще куча всякой мерзости. Хотя для наколенного применения сойдет.

всю жизнь ждал пока вендогеймер даст мне свою оценку апи курла. иди в ие10 смотри свои даунские квадраты. дай людям поработать

Ты лучше расскажи сколько одновременных соединений может держать curl и как у него с серверной частью.

libfetch

чел не дал конкретики что ему надо. вероятнее всего просто получить json с сервера. курл логичное решение

Ты лучше расскажи сколько одновременных соединений может держать curl и как у него с серверной частью.

a хз как у него там, но думаю можно его засунуть в std::async

Как раз тоже нужно разобраться с этой штукой для парсинга http, возможно лучше poco бы, но пока на этом остановимся.

Тогда libcurl, если интересуют плюсы - POCO либо обёртки над libcurl.

ты с POCO работал? - как оно?

какие знаешь достойные обвертки над курлом?

a хз как у него там, но думаю можно его засунуть в std::async

По потоку на соединение это плохо. callback'ки в другом потоке тоже плохо. У curl'а есть multi интерфейс, но он частично блокирующий и по сути проблем не решает.

В каком месте он блокирующий?

Например, в месте работы с dns. В доках про это написано.

У curl'а есть multi интерфейс, но он частично блокирующий и по сути проблем не решает.

ага видел.

я правильно понял что на каждый запрос нужно делать что-то типа

static void *pull_one_url(void *url)
{
CURL *curl;
curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL, url);
curl_easy_perform(curl);
curl_easy_cleanup(curl);
}

чел не дал конкретики что ему надо. вероятнее всего просто получить json с сервера. курл логичное решение

По сути - да, + webdav. Ну и кроссплатформенность. И очень хотелось бы что бы оно собиралось cmake'ом, но это уже не критично. Curl и POCO я так понял пока всё что есть? Lawecing - ограничен вижуал студией или sygwin, а не факт что под винду будет ими собираться.

Мне пх будет оно unix али нет, мне надо что бы оно работало было кроссплатформенно а апи заместо того что бы пугать меня своей навороченостью - помогало работать.

Вообщем POCO - удовлетворяет всем моим требованиям, всем спасибо.

Например, в месте работы с dns. В доках про это написано.

Про DNS понятно, оно в libc блокирующее, curl тут не виноват. Допустим, мы уже отрезолвили адрес (неважно каким способом) и передали его curl. Где еще multi interface может быть блокирующим?

Про DNS понятно, оно в libc блокирующее, curl тут не виноват.

Кто-то заставляет использовать libc для dns?

Вот именно, что никто.

А если использовать какой-нибудь evdns, то почему бы с ним в связке не заюзать evhttp? event-loop будет один и все колбеки будут вызываться в твоем потоке. Это будет гораздо красивее и во всех отношениях проще чем сношательство с curl.