Pull to refresh

Comments 7

Рассмотрел. Применяем, правда, довольно старую версию 5.5 чисто как Actor Model с сетью на boost::asio.

Супер! А на более свежие версии (5.6, 5.7) переходить не планируете?


В so5extra, кстати говоря, есть средства для упрощения интеграции Asio и SObjectizer. Но там standalone Asio пока, про поддержку именно Boost.Asio у нас пока никто не спрашивал.

Глянуть на stable постараюсь, хочется одной библиотеки без танцев с бубном и интергации с бустом.

Интересно, если это мажорные версии (к тому же ломающие совместимость с предыдущими), то почему они соответствующим образом не нумеруются (т. е. 6.0 и 7.0 вместо 5.6 и 5.7)? SemVer ведь не просто так придумали.

Уже отвечал здесь: https://habr.com/ru/post/453256/#comment_20194306
Дополню. SObjectizer v.5.7.0 я воспринимаю как SObjectizer-5 v.7.0.0. А, скажем, SObjectizer v.4.5.0 как SObjectizer-4 v.5.0.0. Соответственно, если появится SObjectizer-6, то он будет настолько сильно отличаться от SObjectizer-5, что можно будет использовать и SO-6, и SO-5, в рамках одного исходного файла, а не только в рамках одного проекта.

Коллеги, а есть ссылка с описанием построения распреденного решения с SO-5? Или есть внутренние рекомендации, в которых указан типовой транспорт и архитектура его интеграции?

В SO-5 нет поддержки распределенности и мы уже рассказывали почему так. Поэтому и такого понятия, как "типовой транспорт" нет. Все будет зависеть от типа задачи и типа транспорта, который в этой задаче будет применяться. Например, если можно использовать брокеры сообщений — это одно, а если нужно будет применять HTTP-запросы (т.е. открыть HTTP-вход и к другим частям приложения обращаться по HTTP) — то совсем другое.


Про опыт использования брокера сообщений и протокола MQTT была отдельная статья.

Sign up to leave a comment.

Articles