Отвечу быстро: В целом хороший подход, но есть несколько вопросов, которые внятно сформулировать я смогу только в выходные. Так что уж обожди :-)
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 > [email protected] > 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/ _______________________________________________ devel-conf mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/devel-conf
