[Devel-conf] alterator backends and IDL definitions

[Aleksey Novodvorsky]

Очень!

Rgrds, Алексей

On 10/11/07, Stanislav Ievlev <stanislav.ievlev на gmail.com> wrote:
> Привет всем!
>
> Хочется обсудить следующую идею: Использование 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