HTTPlug действительно не в кассу, если хочется таких деталей — он больше для простых/средних запросов в публичных библиотеках. Смысл: это проект-обёртка, по сути, чтобы пользователю было удобно подсунуть туда свою текущий HTTP-клиент, который он использует в проекте (Guzzle5, Guzzle6, React HTTP,..). Это удобно для Facebook API SDK, к примеру, чтобы не навязывать в проект Guzzle, к примеру (но и в то же время не писать очередную обёртку над cURL).
Я бы всё таки рекомендовал посмотреть на Guzzle и попробовал на нём запросы. Ошибки на HHVM связаны в основном с генераторами, а вы их и так не используете. С точки зрения интерфейса там всё довольно просто, как по мне, а производительность нужно измерять, с ней других вариантов нет :) Мне кажется, что Guzzle будет не сильно медленнее, учитывая всё остальные плюсы.
Странные примеры реализуются передачей CURLOPT_FILE & CURLOPT_INFILE в объект запроса через опции. Guzzle не имеет поддержки этих функций в своём интерфейсе, но всегда позволяет передать что-то cURL-у «напрямую».
PR не обещаю, т.к. не работаю пока с ClickHouse сам, а переделка глобальная :) Но в деталях помочь могу.
Вопрос касательно последней: почему таки не стали использовать один из готовых HTTP-клиентов? Я видел ремарку об этом в статье, но причины не описаны.
Объясню, почему я считаю, что лучше взять готовый:
— Guzzle или HTTPlug (или подобные) поддерживают promises для асинхронных запросов. Этот подход удобнее, чем Ваш, и, в частности, может быть интегрирован с event loop (тот же React). Ваш клиент я не могу интегрировать с event loop, мне придётся блокироваться для выполнения пачки запросов в любом случае.
— PSR-7 помог бы навешивать всякие middleware на HTTP клиента для библиотеки. К примеру, сейчас мне нужно лезть в кишки, чтобы навесить хитрое журналирование HTTP-запросов, а так бы я просто передал HTTP-клиента, обвешанного моим middleware, при создании клиента и имел бы успех.
Так а что мешает отдельный сервер с Пинбой держать на 5.1? Это же зависимость только для сервера, клиентская библиотека зависимости от MySQL-сервер не имеет.
Asset выглядит «костылём», что ли, если используется только проверки корректности входных параметров и инваринта класса. Для этого есть контрактное программирование (Design By Contract).
Вместо отдельного Selenium'а можно использовать Mink с SahiDriver'ом. Сам, к сожалению, пока не пробовал такого варианта, но выглядит проще и удобнее, чем Selenium.
Было бы очень интересно почитать про приемущества такого способа (deb-пакеты) для обновления сайта перед остальными (svn, к примеру) в отдельной статье. А то методика есть, а цель её не совсем ясна. Да и в Сети таких статей (сравнений методов обновления сайта) я, к сожалению, не нашёл :(
Привести примеры задач, для которых это требуется и т.д.
P.S. Да, в комментариях выше это частично объясняется, но только частично. Хотелось бы более развёрнуто.
«Маршруты здоровья», жесть какая. Пожалуйста, не нужно переводить устоявшиеся термины (healthcheck) с английского.
PHP передаёт привет :)
HTTPlug действительно не в кассу, если хочется таких деталей — он больше для простых/средних запросов в публичных библиотеках. Смысл: это проект-обёртка, по сути, чтобы пользователю было удобно подсунуть туда свою текущий HTTP-клиент, который он использует в проекте (Guzzle5, Guzzle6, React HTTP,..). Это удобно для Facebook API SDK, к примеру, чтобы не навязывать в проект Guzzle, к примеру (но и в то же время не писать очередную обёртку над cURL).
Я бы всё таки рекомендовал посмотреть на Guzzle и попробовал на нём запросы. Ошибки на HHVM связаны в основном с генераторами, а вы их и так не используете. С точки зрения интерфейса там всё довольно просто, как по мне, а производительность нужно измерять, с ней других вариантов нет :) Мне кажется, что Guzzle будет не сильно медленнее, учитывая всё остальные плюсы.
Странные примеры реализуются передачей CURLOPT_FILE & CURLOPT_INFILE в объект запроса через опции. Guzzle не имеет поддержки этих функций в своём интерфейсе, но всегда позволяет передать что-то cURL-у «напрямую».
PR не обещаю, т.к. не работаю пока с ClickHouse сам, а переделка глобальная :) Но в деталях помочь могу.
Ещё раз спасибо за проект!
Вопрос касательно последней: почему таки не стали использовать один из готовых HTTP-клиентов? Я видел ремарку об этом в статье, но причины не описаны.
Объясню, почему я считаю, что лучше взять готовый:
— Guzzle или HTTPlug (или подобные) поддерживают promises для асинхронных запросов. Этот подход удобнее, чем Ваш, и, в частности, может быть интегрирован с event loop (тот же React). Ваш клиент я не могу интегрировать с event loop, мне придётся блокироваться для выполнения пачки запросов в любом случае.
— PSR-7 помог бы навешивать всякие middleware на HTTP клиента для библиотеки. К примеру, сейчас мне нужно лезть в кишки, чтобы навесить хитрое журналирование HTTP-запросов, а так бы я просто передал HTTP-клиента, обвешанного моим middleware, при создании клиента и имел бы успех.
Т.е. можно использовать Builder'ы сами по себе, не касаясь функций.
Эту часть в статье я как раз не раскрыл, т.к. подумал, что будет слишком для одного раза :)
P.S. У тебя, случаем, книжки этой замечательной тётеньки нет в электронном виде? :)
Привести примеры задач, для которых это требуется и т.д.
P.S. Да, в комментариях выше это частично объясняется, но только частично. Хотелось бы более развёрнуто.
P.S. Да и непонятно тогда, зачем YouTube есть.
Просто раньше не задавался вопросом смены SID'а в PHP-приложениях, а теперь нашёл простое решение.