[prog.sobjectizer] Первые наметки к sysconf_3

При разработке SObjectizer-приложений, одной из самых востребованных SObjectizer-овских библиотек оказалась библиотека sysconf. Эта библиотека позволяет собирать приложение из различных DLL как из кирпичиков. Благодаря этому при разработке нового проекта прикладная функциональность разрабатывается в виде новой DLL (нескольких DLL), к которой добавляется еще 5-10 уже готовых, написанных и протестированных ранее компонентов. Например, компоненты для логирования, сбора и распространения мониторинговой информации, организации коммуникационных каналов, маршрутизации сообщений в распределенных приложениях и пр.

Библиотека sysconf была самой первой написанной для SObjectizer-а библиотекой, ее первая версия, sysconf_1, появилась летом 2002-го года. Вторая версия, sysconf_2, если мне не отшибает память, была написана через год. С тех пор sysconf_2 плавно эволюционировала и добралась до версии 2.4.2.

Думаю, что теперь пришло время для создания третьей версии sysconf-а. Чтобы устранить проблемы, которые были заложены в sysconf_1 и sysconf_2 при рождении.

Во-первых, нужно устранить объявление coop_handler-ов и coop_factory в виде глобальных переменных. Поскольку:

• это ведет к проблемам. Т.к. действия по регистрации coop_handler/coop_factory выполняются в конструкторах глобальных переменных во время инициализации загруженной DLL, то это может приводить к тупикам. Поскольку не рекомендуется из DllMain выполнять взаимодействие с другими нитями приложения;
• затрудняет процесс обработки sysconf-скрипта. Sysconf сейчас вынужден загрузить DLL, потом перейти в режим ожидания сообщений от конструкторов coop_handler/coop_factory, а потом возобновить свою работу с точки останова;
• затрудняет процесс создания GUI-инструментов, которые бы показывали состав компонентов в DLL и позволяли пользователю запускать/останавливать компоненты.

Пока идея заключается в том, чтобы DLL экспортировала специальную функцию, возвращающую описания всех coop_handler/coop_factory из DLL. Тогда sysconf после загрузки DLL находит эту функцию через GetProcAddress, вызывает и получает готовое описание. Данное описание будет использоваться sysconf-ом для формирования списка доступных компонентов. Так же это описание смогут использовать внешние GUI-инструменты для отображения данной информации пользователю.

Предполагается, что данная функция-описатель будет возвращать ссылку на статические описания. Т.о. не будут возникать тупиковые ситуации при загрузке DLL, т.е. никакой сложный код в DllMain запускаться не будет.

Во-вторых, нужно упростить формирование sysconf-скриптов. Сейчас, чтобы создать sysconf-скрипт для нового приложения, приходится прибегать к технике copy-paste. Т.е. находится какой-нибудь подходящий, написанный ранее для другого проекта скрипт и он модифицируется для нужд нового проекта. Что не есть хорошо, поскольку это и ошибками черевато, и временами ведет к загрузке совершенно ненужных для конкретного проекта DLL.

Текущая идея состоит в том, чтобы для каждой sysconf-овской DLL разработчиком был создан некий файл описания (например, с жестко заданным именем module.sysconf). В этом module.sysconf будут описаны все coop_handler/coop_factory из DLL и, возможно, какая-то дополнительная информация (например, зависимости от других модулей). Думаю, будет удобно, если и упомянутая раньше функция, возвращающая sysconf-у описание DLL, будет генерироваться в compile-time из module.sysconf.

В sysconf_3 будет включен инструмент (желательно с GUI), который просканирует все имеющиеся в проекте module.sysconf файлы и выведет пользователю их список с дополнительной информацией. Пользователю останется только отметить нужные ему компоненты и инструмент сам сформирует sysconf.cfg с учетом зависимостей выбранных модулей.