Данный пост продолжает тему, затронутую в двух декабрьских постах "Попытка упростить работу с отложенными сообщениями в SO-5" и "Еще одна попытка упростить работу с отложенными сообщениями в SO-5". В результате длительного и напряженного выкуривания бамбука удалось придумать, как же это все должно выглядеть. И уже начала дышать одна из реализаций. Кому интересно, милости прошу под кат. Для тех же, кто не интересуется SObjectizer-ом и C++ными наворотами, ничего интересного в данном посте не будет. Извините.
суббота, 13 января 2018 г.
среда, 10 января 2018 г.
[prog.c++] Мой доклад приняли на C++Russia 2018
Собственно, вот: "Акторы на C++: стоило ли оно того?" Только акторы в докладе будут присутствовать постольку-поскольку, просто как некий фон, демонстрирующий особенности "предметной области". В основном же речь будет идти о C++. О том, насколько C++ помогал в разработке, где и когда мешал. Как менялся C++ и как это сказывалось. И как сказывалось то, что где-то C++ не менялся. Как изменилось отношение к C++ за прошедшие 15 лет и как это повлияло на нашу работу.
В общем, это будет доклад не про SObjectizer, а про то, что "С++, конечно, та еще субстанция, но конфетку-то сделать можно" ;)
понедельник, 8 января 2018 г.
[prog] Не Boost-ом единым...
Разведка донесла, что в slack-канале Boost-а проскочила ссылка на RESTinio-0.4. В ответ на что Винни Фалько, автор Boost.Beast, запостил ссылку на этот issue с предложением задействовать Boost.Beast в реализации RESTinio. И добавил к этой ссылке фразу: "The old "boost bad" canard."
Хочется сказать, что Винни не прав. В том, что мы не стали делать RESTinio на базе Boost.Beast, нет никакого подтекста из категории "Boost -- говно". Попробую объяснить, почему мы не хотим добавлять Boost.Beast в зависимости к RESTinio. Хотя такая идея нами обсуждалась где-то в мае или июне 2017-го, когда стало известно о сроках проведения review для включения Beast-а в Boost.
Первая причина в том, что С++разработчики, как уж сложилось, делятся на тех, кто использует Boost, и на тех, кто Boost не использует. Нам сейчас не важно, по каким причинам кто-то не использует Boost. Важно, что такой факт имеет место быть. И что разработчиков, которые не используют Boost, не так уж и мало. Пусть даже таких, грубо говоря, всего 10%, но это все равно не 0%. Следовательно, если мы сделаем RESTinio на базе Boost.Beast, то эти разработчики просто не будут рассматривать RESTinio. Для нас эти разработчики, как потенциальные пользователи, будут потеряны. Тогда как если RESTinio не будет иметь Boost в зависимостях, то RESTinio смогут использовать и те, кто применяет Boost, и те, кто держится от Boost-а подальше.
Такова се-ля-ви. Если мы заложимся на Boost, то мы отрежем часть потенциальных пользователей. Нам это не нужно. Как бы представители секты "Boost -- это наше все" не выдрачивали на свой любимый фреймворк, вне Boost-а тоже есть жизнь. И нам она так же интересна. Тем более, что представители секты "Boost -- это наше все" крайне не любят смотреть на то, что в Boost не входит. Вот есть в Boost-е Beast, значит встраиваемый HTTP-сервер нужно делать именно на Beast. И похер на то, что это займет больше времени и кода, зато Boost и вот это вот все. Так что даже с точки зрения банального маркетинга в большой аудитории пользователей Boost-а процент тех, кто не удовлетворится Beast-ом и пойдет искать что-то еще, очень невелик. Посему ценность этой аудитории будет не выше, чем ценность аудитории тех, кто Boost не использует. Значит, нам тем более нет смысла терять аудиторию тех, кто не использует Boost.
Вторая причина в том, что Beast берет на себя слишком много. Закладываясь на Beast мы лишаем себя значительной части контроля над тем, что происходит с вводом-выводом и парсингом HTTP-протокола. Тогда как http-parser из nodejs (как и picohttpparser) в этом смысле гораздо менее требовательные. Это позволяет нам, например, встраивать контроль за тайм-аутами операций. И еще, к примеру, у нас остается возможность дать разработчикам выбор между HTTP-парсерами: сейчас поддерживается только nodejs-овский http-parser, но если будут пожелания от пользователей, то мы можем добавить альтернативы. Тот же picohttpparser. Или даже какой-то кастомный, заточенный под одну конкретную задачу.
Т.е. контролируя почти все, что связано с вводом выводом и обработкой прочитанных/записываемых блоков данных, мы имеем большую гибкость. А так же свободу развернуть RESTinio в нужном нам и нашим пользователям направлении. Тогда как с Boost.Beast мы такой гибкости не видим.
Подчеркну еще раз. Мы уже обсуждали тему перевода RESTinio на базу Beast-а. И коллективно решили, что это не в наших интересах. У разработчика Boost.Beast своя задача. У нас своя.
Мы хотим сделать инструмент, который был бы максимально удобен для конечного пользователя. Нужно пользователю создать HTTP-сервер? Пусть напишет всего 10 строк кода. Нужно ему, скажем, добавить какой-то механизм защиты от перегрузки? Пусть допишет еще 2 строки кода. Нужно пользователю убрать какую-то фичу за ненадобностью? Пусть поменяет одну строку из этих двенадцати. Имея собственную реализацию сервера мы можем это сделать. В том числе и потому, что мы можем затачивать под это используемые в реализации структуры данных и даже принципы работы фреймворка.
Тогда как у разработчика Boost.Beast, на мой взгляд, цели совсем другие. Beast представляет из себя низкоуровневый конструктор, из которого, при желании, приложив достаточно сил и времени, можно собрать что угодно. Для каких угодно целей. Но, повторюсь, приложив достаточно времени и сил.
Можно ли в RESTinio совместить то, что хотим мы, с тем, что закладывалось в сам Beast? Может быть и можно. Хотя, как нам представляется, не просто. И, если бы мы начинали делать RESTinio сейчас, после релиза Boost-1.66, вопрос реализации RESTinio на базе Beast-а можно было бы рассматривать более внимательно. Но начали мы делать RESTinio сильно раньше. И переходить на Beast сейчас, с учетом всего вышесказанного, вряд ли разумно.
Если кто-то думает, что мы из тех, кто принципиально не использует Boost, то это зря. Случается, что и используем. Следы этого на публике можно обнаружить, например, в прототипе интеграции SObjectizer-а и libmosquitto. Но когда речь заходит о библиотеке, предназначенной для широкого использования, то вопрос помещения Boost-а в список зависимостей перестает быть праздным.
Подписаться на:
Сообщения (Atom)