поиск здесь и по гуглю ничего внятного не дал. Посему решил провести небольгой соцопрос
Кто чем пользуется для работы с HTTP в своих приложениях?
Что нужно: возможность выполнения асинхронных запросов, возможность отмены, показ прогресса (или легкая воможность прикрутить оный).
Основное требование — высокоуровневость и простота использования, вместе с тем достаточная гибкость и возможность тонкой настройки.
Здравствуйте, astral_marine, Вы писали:
_>Посмотрите: _>- Встраевыемый Internet Explorer в окно, как ActiveX _>- WinInet functions _>- cURL
_>Остальной пользовательский интерфейс пишется самостоятельно
cURL по определенным причинам использовать не могу — иначе бы не спрашивал).
Internet Explorer мне не нужен, явный оверкилл, мне просто GET запрос сделать надо.
А ты реально пробовал WinInet использовать в асинхронном режиме или просто так сказал?
Здравствуйте, jedi, Вы писали:
J>Что нужно: возможность выполнения асинхронных запросов, возможность отмены, показ прогресса (или легкая воможность прикрутить оный). J>Основное требование — высокоуровневость и простота использования, вместе с тем достаточная гибкость и возможность тонкой настройки.
Под "показом прогресса" понимается не ГУЙ с прогресс баром), а просто какой-то колбек позволяюший самому такой гуй прикрутить. А то тут меня уже неправильно поняли.
P.S. Я не совсем ламер, так что не нужно ответов типа кури WinInet, cURL итп. Мне просто интересно кто что использует — достаточно
высокоуровневое, стабильное, настраиваемое, написанное в С++ стиле.
Здравствуйте, jedi, Вы писали:
J>Кто чем пользуется для работы с HTTP в своих приложениях?
Я в ближайшее время планирую попробовать соответствующие классы из wxWidgets. По описанию выглядит довольно неплохо.
Здравствуйте, Slava Tutushkin, Вы писали:
ST>Здравствуйте, jedi, Вы писали:
J>>Кто чем пользуется для работы с HTTP в своих приложениях? ST>Я в ближайшее время планирую попробовать соответствующие классы из wxWidgets. По описанию выглядит довольно неплохо.
Уже ближе к делу). Смотрел некоторое время назад. Нет (или не понял как) возможности асинхронной работы — те запустить например десяток одновременных даунлоадов в одном потоке.
Но все равно спасибо , посмотрю мож че в последней версии изменилось.
Здравствуйте, jedi, Вы писали:
J>Привет всем,
J>поиск здесь и по гуглю ничего внятного не дал. Посему решил провести небольгой соцопрос J>Кто чем пользуется для работы с HTTP в своих приложениях?
J>Что нужно: возможность выполнения асинхронных запросов, возможность отмены, показ прогресса (или легкая воможность прикрутить оный). J>Основное требование — высокоуровневость и простота использования, вместе с тем достаточная гибкость и возможность тонкой настройки.
J>Всем сасибо.
можно посмотреть MSXML4::IXMLHTTPRequest/IServerXMLHTTPRequest2
Здравствуйте, jedi, Вы писали:
J>Под "показом прогресса" понимается не ГУЙ с прогресс баром), а просто какой-то колбек позволяюший самому такой гуй прикрутить. А то тут меня уже неправильно поняли.
Ну тогда это URLDownloadToFile, URLOpenStream и прочие URL моникеры.
Здравствуйте, Константин Л., Вы писали:
КЛ>можно посмотреть MSXML4::IXMLHTTPRequest/IServerXMLHTTPRequest2
КЛ>асинхронность есть, мониторинга прогресса нету
Спасибо, посмотрю. Правда смущает, то что уж очень микрософто-зависимо — сейчас это не важно, но есть перспектива переноса проги под линух и мак.
Так что забыл еще одно требование — кроссплатформенность между основными платформами (палмы и симбианы не важны
Здравствуйте, algol, Вы писали:
A>Здравствуйте, jedi, Вы писали:
J>>Под "показом прогресса" понимается не ГУЙ с прогресс баром), а просто какой-то колбек позволяюший самому такой гуй прикрутить. А то тут меня уже неправильно поняли.
A>Ну тогда это URLDownloadToFile, URLOpenStream и прочие URL моникеры.
Интересно, но не в кассу. Мне нужна гибкость, те возможность задания хидеров итп. Слишком высокоуровнево
Да и не кроссплатформенно.
Понимаю, что я привередливый. Но ведь есть где-то же библиотека моей мечты неужели до сих пор на С++ ничего подобного не написано?
Здравствуйте, jedi, Вы писали:
J>Internet Explorer мне не нужен, явный оверкилл, мне просто GET запрос сделать надо.
Ну так и послать GET и жлать ответа или прибить ожидание когда уже не надо ждать
Некроссплатформенность маловероятна (c) Sheridan
...трава никак не влияет, разве что срывает покровы барьеров... (с) мыщъх
Здравствуйте, olexandr, Вы писали:
J>>Internet Explorer мне не нужен, явный оверкилл, мне просто GET запрос сделать надо. O>Ну так и послать GET и жлать ответа или прибить ожидание когда уже не надо ждать
В-первых не кроссплатформенно, как я уже уточнил. Но это не самое страшное.
Internet Explorer имеет кучу недостаков:
а) он может просто не стоять у пользователя
б) я завишу от его настроек — прокси, сертификаты итп. Понятно, что все настраивается, но это может затронуть другие приложения.
в) это ОВЕРКИЛЛ. мне не нужен броузер, мне нужно выполнить простой GET запрос с возможностью отследить прогресс и отменить в случае необходимости.
г) это не стандартный С++, а COM со всеми вытекающими.
Если бы мне нужен был IE я бы взял его и использовал бы, не создавая этого топика
Здравствуйте, Сергей, Вы писали:
С>В Qt что-то такое должно быть. Но Qt стоит денег.
Да, наверное есть. Но тут тоже проблема — я буду вынужден таскать за собой (и покупать) QT. Сомневаюсь, что это библиотеку отделно от него можно использовать. Все равно спасибо — еще одна версия в копилку
Здравствуйте, jedi, Вы писали:
A>>Ну тогда это URLDownloadToFile, URLOpenStream и прочие URL моникеры. J>Интересно, но не в кассу. Мне нужна гибкость, те возможность задания хидеров итп. Слишком высокоуровнево
С хидерами нет проблем — IHttpNegotiate::BeginningTransaction, и все остальное тоже делается.
J>Да и не кроссплатформенно.
Здравствуйте, jedi, Вы писали:
J>>>Кто чем пользуется для работы с HTTP в своих приложениях? ST>>Я в ближайшее время планирую попробовать соответствующие классы из wxWidgets. По описанию выглядит довольно неплохо. J>Уже ближе к делу). Смотрел некоторое время назад. Нет (или не понял как) возможности асинхронной работы — те запустить например десяток одновременных даунлоадов в одном потоке.
Это ещё надо посмотреть, как оно работает, кстати.
Вопрос в том, как ведёт себя GetInputStream из wxHTTP. Я фантазирую, что оно сразу возвращает управление, а потом, при необходимости, блокируется при чтении из возвращённого потока.
Эти фантазии имеют под собой кое-какую основу: у wxInputStream есть метод CanRead, который, в соответствии с документацией, сообщает, будет ли блок при вызове Read.
В общем, при первом взгляде на документацию, всё выглядит асинхронным.
Здравствуйте, Slava Tutushkin, Вы писали:
ST>Здравствуйте, jedi, Вы писали:
ST>Эти фантазии имеют под собой кое-какую основу: у wxInputStream есть метод CanRead, который, в соответствии с документацией, сообщает, будет ли блок при вызове Read.
Это не асинхронность Что мне это CanRead в цикле вызывать? Или Sleep делать?
Нужны уведомления (те вызов колбека) и/или (даже лучше) что-то похожее на ACE-совский Reactor.
Здравствуйте, jedi, Вы писали:
ST>>Эти фантазии имеют под собой кое-какую основу: у wxInputStream есть метод CanRead, который, в соответствии с документацией, сообщает, будет ли блок при вызове Read. J>Это не асинхронность Что мне это CanRead в цикле вызывать? Или Sleep делать? J>Нужны уведомления (те вызов колбека) и/или (даже лучше) что-то похожее на ACE-совский Reactor.
Ооокей, а ещё есть вот такое:
wxSocket events
wxSOCKET_INPUT There is data available for reading.
wxSOCKET_OUTPUT The socket is ready to be written to.
wxSOCKET_CONNECTION Incoming connection request (server), or successful connection establishment (client).
wxSOCKET_LOST The connection has been closed.
ST>wxSocket events
ST>wxSOCKET_INPUT There is data available for reading.
ST>wxSOCKET_OUTPUT The socket is ready to be written to.
ST>wxSOCKET_CONNECTION Incoming connection request (server), or successful connection establishment (client).
ST>wxSOCKET_LOST The connection has been closed.
ST>
ST>В общем, всё равно всё хорошо.
Неа (вредный я)... Это я должен на уровень сокетов спуститься. Если так то нафига мне вообще специальный HTTP класс? Я могу и руками по HTTP общаться, вот только геморно это. Да и как быть с тем же HTTPS? А с асинхронной отсылкой запроса или приемом респонз хидеров? А с резолвингом днс перед подключением, а с самим подключением? — то что ты показал будет работать только во время приема Response stream-а.
В общем полумеры не нужны, интересует ultimate solution
, посмотрю мож че в последней версии изменилось.
