Ув.тов.Alex Syrnikov в предыдущей заметке оставил очень хороший комментарий-вопрос на тему возможности сравнения SObjectizer и Qt на какой-то приближенной к реальности задаче. Комментарий большой, я его не буду копипастить, а смысл его сводится к тому, чтобы попробовать решить какую-то задачу на SObjectizer и Qt, а затем сравнить получившиеся результаты.
Идея интересная и хорошая, я обязательно над ней подумаю. А если кто-то из читателей предложит конкретную задачу, то это сделает претворение данной идеи в жизнь намного более вероятным. (Upd. Возможно, для этой цели подойдет простенькая задачка про хамелеонов, с решением которой у меня когда-то были приключения.)
Пока же позволю себе небольшой поток воспоминаний. Изначально SObjectizer-4, появившийся на свет весной 2002-го, не нуждался в сторонних библиотеках, в нем все было свое: свои классы для работы с многопоточностью, с сетью, с DLL-ками. Со временем поддерживать это хозяйство самостоятельно становилось все сложнее и сложнее, поэтому где-то в 2004-м или 2005-м мы начали искать C++ную библиотеку, которая стала бы обеспечивающим кроссплатформенность базовым слоем. Рассматривались самые разные библиотеки, названий многих из которых я сейчас даже и не вспомню. Там были и С-шная APR, и GNU-тая Common C++, и POCO, и wxWidgets. Но выбор делался из ACE, Boost и Qt. Остановились на ACE, хотя решение это было очень не простым.
До сих пор меня время от времени терзает мысль, что если бы мы выбрали Qt в качестве базового слоя, то все могло бы сложиться иначе :) Наверняка тогда было бы две лицензии на SObjectizer -- GPL и коммерческая :))) И, возможно, сейчас бы я не думал над тем, как на SObjectizer зарабатывать деньги... ;)
Тем не менее, это явно был случай, когда не было однозначно правильного решения, да еще и с учетом исторического послезнания. Это же были времена Qt3, разрабатывавшейся еще TrollTech-ем с прицелом только на GUI. Вряд ли кто-то предполагал, что TrollTech будет куплен Nokia, Qt4 сделает огромный шаг в сторону поддержки не-GUI приложений, а сама Qt появится еще и под LGPL лицензией. Оглядываясь назад, я считаю, что выбор ACE вместо Qt себя все-же оправдал. По крайней мере, было много случаев, когда для поиска проблем нужно было глубоко погружаться в код ACE и стиль ACE-овского кода, а так же относительно небольшой объем ACE (в сравнении с Qt) позволял легко это делать.
Но время идет вперед, все развивается. С++11 уже содержит множество механизмов, которые нужны были ядру SObjectizer от ACE. Поэтому лично у меня есть желание максимально отвязаться от ACE в SObjectizer core. Уже сейчас SObjectizer-5 представлен в виде набора построенных друг над другом библиотек. Основа -- это библиотека so_5, которая поддерживает понятия сообщение, агент, состояние, диспетчер и т.д. А уже на so_5 наслаиваются дополнительные библиотеки, упрощающие разработку больших и/или распределенных приложений на SObjectizer: so_sysconf (построение приложения из DLL, как из кирпичиков), so_5_transport (поддержка TCP/IP соединений посредством SO-агентов), mbapi (обмен сообщениями, в том числе и в распределенной среде).
Так вот мне хотелось бы отказаться от ACE в so_5, оставив использование ACE только там, где требуется работа с системой (so_sysconf, so_5_transport), чтобы so_5, ядро SObjectizer, было минималистичным и не имело бы внешних зависимостей. Но сейчас этому препятствует две вещи: хорошая реализация таймеров в ACE, а таймерные сообщения -- это один из краеугольных камней SObjectizer, и задействование ACE Logging в коде всех SObjectizer библиотек. Поэтому далеко не факт, что от ACE получится избавится и обойтись только возможностями C++11 и своими собственными силами.
Однако, как я уже сказал, жизнь не стоит на месте, все течет, развивается и изменяется. Будущее SObjectizer уже не определяется только нуждами и задачами Интервэйла. Поэтому, если будут веские доводы сменить ACE в качестве базового слоя для SObjectizer на Boost или Qt, то почему бы и не обдумать такой вариант.
PS. На данный момент SObjectizer зависит не только от ACE, но и от Ruby. Впрочем, если бы в качестве системы сборки использовался SCons, то была бы зависимость от Python. Тут уж должен сработать принцип OpenSource -- авторы библиотеки используют то, что удобно им. А если кто-то хочет иметь что-то еще и у него есть время/желание/возможность воплотить это в жизнь, то милости просим... :)
Комментариев нет:
Отправить комментарий