Мотивация

Работа над веткой 5.5 началась более 4.5 лет назад. В условиях, когда приходилось использовать компиляторы без вменяемой поддержки даже C++11, не говоря уже про C++14. Все это время SObjectizer-5.5 развивался во-первых, с серьезной оглядкой на старые C++ компиляторы и, во-вторых, с максимальным сохранением совместимости между версиями в рамках ветки 5.5. Кроме того, SObjectizer-5.5 унаследовал ряд проектных решений из еще более ранних версий SObjectizer-5.

В результате в реализации SObjectizer-5.5 накопились "косяки", которые были обусловлены как просчетами при проектировании, так и невозможностью использовать новые версии стандарта C++. Исправить эти косяки без нарушения совместимости между версиями не представляется возможным.

В условиях 2019-го года продолжать развитие ветки 5.5 с оглядкой как на ограниченное подмножество C++11, так и на совместимость с проектными решениями, принятыми 4.5 года назад не представляется более ни разумным, ни экономически оправданным.

Цель разработки SObjectizer-5.6

Целью разработки ветки 5.6 является устранение проблем ветки 5.5 при сохранении основных принципов работы SObjectizer-5, но без стремления обеспечить 100% совместимость с веткой 5.5.

Планируемые изменения в SObjectizer-5.6

Изъятие всего того, что в SObjectizer-5.5 было помечено как deprecated.

За более чем 4 года развития ветки 5.5 множество вещей было помечено как deprecated. Например, пространство имен so_5::rt или функция send_delayed_to_agent. Из-за сохранения совместимости все это еще присутствует в SObjectizer-е и, более того, работает.

Однако, пришло время избавить кодовую базу SObjectizer-а от этого старого хлама.

Каждый mbox будет содержать ссылку на SObjectizer Environment

В SObjectizer-5.5 через mbox нельзя получить ссылку на SObjectizer Environment, хотя это можно было бы сделать для MPSC-mbox-а. Тогда как через mchain ссылку на SObjectizer Environment получить можно. При этом mchain может трансформироваться в mbox, а из mbox доступа к Environment-у нет.

Если в mbox-е будет хранится ссылка на SObjectizer Environment, то получится сделать send_delayed и send_periodic унифицированными. Т.е. вызов send_delayed(mbox, pause, args) будет выглядеть так же, как и send_delayed(agent, pause, args).

Сокращение количества способов отослать сообщение

Сейчас в SObjectizer-5.5 по историческим причинам накопился ряд методов для отсылки сообщений (например, различные варианты deliver_message в классе abstract_message_box_t) и выполнения синхронных запросов. Здесь нужно навести порядок и оставить лишь самый необходимый минимум в классах abstract_message_box_t, environment_t, а также останется только ряд шаблонных функций send, send_delayed, send_periodic, request_value и request_future.

Сокращение количество разрешенных форматов обработчиков сообщений

Останется поддержка только двух следующих форматов:

ret_type event_handler(mhood_t<msg_type>); // for messages and signals.
ret_type event_handler(const mhood_t<msg_type> &); // for messages and signals.

Останутся только обычные агенты, ad-hoc агенты будут удалены

Практика показывает, что определить обычного агента, который выполняет какие-то простые действия, прямо "по месту" в современном C++ совсем не сложно. Поэтому затраты на поддержку ad-hoc агентов в SObjectizer-е не соответствуют той выгоде, которую ad-hoc агенты дают.

Будет изъята поддержка tuple_as_message

После того, как в SObjectizer-5.5 появилась возможность отсылки сообщений произвольных пользовательских типов (без необходимости наследования от so_5::message_t), надобность в функциональности tuple_as_message, фактически, отпала.

Будет устранено деление на публичные и приватные диспетчеры

Исторически в SObjectizer-е были только публичные диспетчеры. Затем были добавлены приватные диспетчеры, которые и рекомендуются к использованию. Поддержка и публичных, и приватных диспетчеров усложняет API SObjectizer-а и привносит дополнительные расходы на его развитие и сопровождение. Поэтому в SObjectizer-5.6 останутся только приватные диспетчеры.

Будет проведена чистка API

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

Где будут жить исходники SObjectizer-5.6?

До сих пор исходники SObjectizer-а жили в Subversion репозитории на SourceForge с экспериментальным зеркалом на GitHub-е. Для SObjectizer-5.6 это уже будет не так.

Во-первых, скорость работы с Svn на SF.net в последнее время стала недостаточно хорошей. И сам Svn-репозиторий на SF.net время от времени оказывается недоступным.

Во-вторых, хотелось бы иметь более простую интеграцию с сервисами, вроде TravisCI, без процедуры зеркалирования куда-то Svn-репозитория.

В качестве основного варианта пока рассматривается разработка SO-5.6 непосредственно на GitHub-е (с именем вида https://github.com/Stiffstream/sobjectizer-5.6). Но кое-кто из разработчиков SObjectizer-а (например, eao197) не любит ни git, ни GitHub.

Поэтому есть альтернативный вариант -- Mercurial-репозиторий на BitBucket-е (с именем вида http://bitbucket.org/sobjectizerteam/sobjectizer-5.6). С зеркалом на GitHub. Благо Hg зеркалируется в git гораздо проще.

Решение по этому вопросу еще не принято.

Соответственно, сопутствующие проекты, т.к. timertt и so_5_extra, будут жить в отдельных репозиториях на том же самом хостинге, что и SObjectizer-5.6. Управление зависимостями будет построено на базе MxxRu::externals.

Где будет жить документация по SObjectizer-5.6?

Открытый пока вопрос. Есть три основных варианта.

1. Размещение документации по новой версии в Wiki проекта на SourceForge. Чтобы вся документация была собрана в одном месте. Кроме того, в этом варианте проще писать новую документацию, т.к. можно переделывать старую.

2. Размещение документации в Wiki того репозитория, в котором будут размещаться исходники SObjectizer-5.6.

3. Размещение документации на сайте stiffstream.com, как это сейчас происходит, например, с документаций по RESTinio.

Какая версия стандарта C++ будет использоваться для разработки версии 5.6?

Есть большое желание сразу использовать C++17. И, соответственно, в качестве минимальных версий компиляторов рассматривать GCC 7, clang 6 и Visual C++ 15.9.3. Либо даже GCC 8, clang 7 и VC++ 15.9.3.

Требования к стандарту C++ можно уменьшить до C++14, но только в случае, если кто-то объяснит, почему это важно. Если никто не попросит о поддержке C++14, то ее и не будет.

С++11 не будет поддерживаться в принципе. Если вам это, действительно нужно, то рассмотрите, пожалуйста, вариант коммерческой поддержки SObjectizer-а.

Что по срокам?

Разработка SObjectizer-5.6, как предполагается, будет состоять из двух стадий.

На первой стадии происходит чистка исходного кода SObjectizer-а и формирование основной кодовой базы SObjectizer-5.6. Плюс адаптация уже написанной документации и учебных материалов к особенностям версии 5.6. Завершается эта стадия выпуском версии 5.6.0. Если все будет идти нормально, без форс-мажоров, то ожидать релиза 5.6.0 можно к концу февраля 2019-го.

Следующая стадия начнется после релиза версии 5.6.0. Она подразумевает расширение SObjectizer-5.6 новой функциональностью. Т.е. новые фичи будут добавляться не в SO-5.5, а в SO-5.6.

Какое время жизни планируется у SObjectizer-5.6?

Предположительно, SObjectizer-5.6 будет актуален до конца 2019-го года. Дальше мы пока не загадываем.

На развитие SObjectizer-5.6 прямое влияние будет оказывать его востребованность. Чем больше людей будет использовать SO-5.6 и будет высказывать заинтересованность в нем, тем дольше мы будет развивать ветку 5.6 обеспечивая максимально возможную совместимость между версиями внутри ветки, как это происходило с веткой 5.5.

Что будет дальше с SObjectizer-5.5?

Ничего.

До момента релиза SObjectizer-5.6.0 мы будет устранять найденные в SObjectizer-5.5 проблемы и выпускать обновления. После релиза версии 5.6.0 какое-либо развитие ветки 5.5 будет остановлено.

Если вам необходима дальнейшая поддержка SObjectizer-5.5, то вы можете обратиться к нам за коммерческой поддержкой.

Как вы можете повлиять на развитие SObjectizer-а?

Мы всегда прислушиваемся к пожеланиям наших пользователей. Поэтому если вы найдете возможность высказать свое мнение о том, каким вы видите SObjectizer-5.6, что вы хотели бы там иметь, чтобы вы из SObjectizer-а выбросили бы, устраивает ли вас использование стандарта C++17, напрягает ли вас хостинг проекта на BitBucket-е и т.д., то вы окажете нам существенную помощь в выборе вектора дальнейшего развития SObjectizer-а.

Поэтому есть альтернативный вариант -- Mercurial-репозиторий на BitBucket-е

Есть ещё gitlab: теже фичи что и у github/bitbucket но ещё и с опциональной возможностью развернуть на своих мощностях (не особо нужно для опен-сорсных проектов, но всё же), ну и приватные репозитории там давно раздают (мало ли надо).

@basiliscos Приватные репозитории сейчас есть и на github-е.

На данный момент черновая версия SO-5.6 разрабатывается в приватной репе на bitbucket-е. Когда появится что-то более-менее пригодное для показа будем решать куда размещать основной репозиторий. На данный момент основной рабочий вариант: bitbucket+hg с зеркалом на github-е.

Логический финал этой истории: релиз SObjectzer-5.6.0.