[devel] D-BUS API tracking in repositories

[devel] D-BUS API tracking in repositories

[Alexander Bokovoy]

Коллеги,

каким образом можно организовать отслеживание изменений в динамически
предоставляемых API, наподобие экспортируемых через D-BUS на уровне
репозитария? Эта проблема актуальна для тесно связанных между собой на
основании динамических интерфейсов программных комплексов. Таковыми на
сегодня являются как десктопные системы, так и специализированные
решения, чаще всего в области мобильных коммуникаций.

Попытаюсь объяснить ситуацию на примере того же D-BUS:
1. Для работы клиента и сервера между собой в D-BUS не требуется
наличие никаких внешних файлов описания интерфейсов, кроме
минимального файла конфигурации службы для ее запуска, если такая
служба еще не зарегистрирована в d-bus:
# Sample service description file
[D-BUS Service]
Names=org.freedesktop.ConfigurationDatabase;org.gnome.GConf;
Exec=/usr/libexec/gconfd-2
Все остальное не требует наличия каких-либо внешних средств. Во время
работы системы все ее свойства можно вывести путем интроспекции
интерфейсов.

2. Для получения свойств каждого интерфейса требуется запускать
приложение. Это невозможно в системе тестирования целостности
репозитария.
3. Каким образом можно организовать обнаружение изменений интерфейсов?

Мой текущий взгляд на проблему изложен ниже.
0. Используя пакетные зависимости и символы ELF можно достоверно
обнаружить компоненты пакетной базы, экспортирующие динамические
интерфейсы для статически связанных систем (меня интересуют сейчас
именно такие, вопросы скриптовых языков я преднамеренно опускаю).
1. Довольно часто в исходном коде приложений используются внешние
текстовые описания интерфейсов, аналогичные получаемым в процессе
интроспекции интерфейса в run-time. Некоторые приложения и среды
разработки используют их для генерирования исполняемого кода,
реализующего интерфейс и его использование.
2. Обнаружив компоненты, экспортирующие динамические интерфейсы, можно
выполнить анализ исходного кода на предмет наличия в них таких
описаний и на основании их составить базу интерфейсов репозитария
(первое приближение).
3. Для приложений, где такие текстовые описания интерфейсов не
используются необходимо придумать что-то еще.

В моем случае есть возможность организационно обеспечить
документирование интерфейсов, однако это довольно трудоемкий процесс в
смысле поддержания целостности продукта после создания начальной
информационной базы. Хотелось бы организовать автоматическое или
полуавтоматическое отлавливание самых типичных случаев "разрушения"
API при эволюционировании проекта.

-- 
/ Alexander Bokovoy