[Devel-conf] alterator backends and IDL definitions

[Stanislav Ievlev]

Привет всем!

Хочется обсудить следующую идею: Использование IDL при создании
бакендов alterator. Начну издалека.

Есть известная проблема контроля типов параметров передаваемых бакенды.
В своё время для решения этой проблемы были сделаны так называемые
constraints -   декларативное описание параметров бакендов и связей
между ними.

Идея состояла в том чтобы автор бакенда не писал нудные проверки типа
"является ли эта штука ip-адресом", а с другой стороны средство
отображение интерфейса автоматически подхватывала и использовала
полученные знания.

Тип параметра превращался в проверки введённых в поле значения. А
связи между параметрами превращались например в "включение и
выключение" отдельных полей, в зависимости от включения/выключения
checkbox.

Идея с типизацией себя оправдала полностью, а вот автоматика по
визуализации связей постоянно давала сбои - уж очень сложная она
оказалась.

Назрела необходимость заменить constraints на что-то новое. Я хочу
заменить их на IDL-описания интерфейса бакенда. И этим самым надеюсь
сразу убить нескольких зайцев:

1. Бакенды и так уже по сути RPC, нечего тянуть дальше. Из
IDL-описаний будет легче переходить к DBUS,SOAP и прочим интересным
шинам. WSDL возможно кошернее, но это уже не для людей, а для eclipse
и прочих полуавтоматических генераторов кода.

2. Сейчас почитав код шельных бакендов отдельных авторов невозможно
понять как обратиться к этому бакенду. А тут под боком всегда будет
уже готовый документ. Не обязательно даже писать комментарии,
достаточно просто взглянуть на описание интерфейса.


3. Не будет зависимости на протокол между бакендом и фронтендом. А
стало быть можно будет использовать одни и те же бакенды хоть для
alterator, а хоть для connexion. Упоминание последнего здесь не
спроста - в alterator и  connexion используется принципиально разная
модель конфигуратора ;)

4. Есть ряд особенностей программирования message_loop у бакенда в
alterator, если ошибиться , можно получить интересные подземные стуки.
Ныне предполагается, что эта часть будет сгенерированна автоматически.

--

Предполагается такая схема работы (которая будет заставлять
пользователя использовать IDL). Человек пишет IDL, на основании этого
генерится файл для реализации. В самом распространённом случае для
alterator - бакенд на shell - это файл с кучей функций типа
interfacename_param_read interfacename_param_write ...
Способ генерации имён вполне понятен при изменении IDL, можно будет не
перегенерировать файл реализации заново, а просто добавить функции (в
будущем можно будет конечно соорудить что-то типа msgmerge ;) )

В пакет кладётся собственно IDL и файл с реализации.
Далее или при установке или при первом использовании  (это как будет
удобнее) генерится собственно бакенд в который соурсится код с
реализацией ну и он как обычно используется с alterator.

Специально для любителей обратной совместимости:
Ничего старого эта схема не отменяет. Всё что уже написано как
работало так и будет работать и постепенно переписываться на новые
рельсы.
Сгенерированный при помощи IDL код будет работать со старым alterator ;)

 А для перешедших на новую схему просто появятся дополнительные бонусы.

--
Что думаете?