Привет всем! Хочется обсудить следующую идею: Использование 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
