[Devel-conf] alterator backends and IDL definitions

[Alexander Bokovoy]

Отвечу быстро:

В целом хороший подход, но есть несколько вопросов, которые внятно 
сформулировать я смогу только в выходные. Так что уж обожди :-)

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 ;)
> 
>  А для перешедших на новую схему просто появятся дополнительные бонусы.
> 
> --
> Что думаете?
> _______________________________________________
> devel-conf mailing list
> devel-conf на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-conf


-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/