[Devel-conf] I: idl - окончательный вариант

Stanislav Ievlev =?iso-8859-1?q?stanislav=2Eievlev_=CE=C1_gmail=2Ecom?=
Ср Окт 31 12:25:02 MSK 2007


Просмотрел множество существующих вариантов и ни один меня не устроил ;)

xml и рядом с ними не для людей, а для роботов
ldif - это скорее протокол для общения с бакендом, нежели описание
схемы, а вот схемы в ldap - это точно не для слабонервных.
idl - идея хорошая, но всё-таки это Interface dl, а интерфейс это
прежде всего функции, а не данные. В тех ООП языках где данные могут
появляться в интерфейсе во всех книжках пишут "ну вы напишите конечно
данные, но тут же сделайте методы-обёртки для изменения их" ;)

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

Предлагаю формат такой:
Есть несколько секций, каждая секция описывает свой фрагмент дерева.
Содержимое каждой секции:
/path/inside/tree nodeparam1 nodeparam2
 type1 name1 argparam1
 type2 name2 argparam2

Например:
/net-general
    hostname host
    domainname domain

/users list name
    string name required
    integer uid readonly
    string password writeonly

Надеюсь идея понятна.
Теперь на основании этого описания (пусть называется schema и лежит в
/usr/share/alterator/schemas) можно сгенерить заготовку для реализации
и собственно код бакенда.

Схема генерации следующая:
кусок дерева /a/b/c превращается в серию функций:
a_b_c_read, a_b_c_write, a_b_c_list, a_b_c_item.
Первые два читают/записывают параметры этого узла.
Вторые два предназначены для списка однотипных объектов. Один для
считывания одного экземпляра, второй для получения списка

Для shell:

Внутри функций *_read и *_write работа идёт очень похожим на современный способ:
глобальные переменные $in_arg1 $in_arg2 олицетворяют входные данные, а
(вот тут отличие) глобальные переменные $out_arg1, $out_arg2
олицетворяют выходные данные.
Задача функции заполнить нужные переменные.

Кстати заодно мы избавляемся от проблемы засорения stdout (которая
столь часто есть в нынешнем backend3).
функции реализации вызываются с перенаправлением stdout в stderr, а
потом уже сгенерированный код огранизующий протокол выводит в stdout
ровно то что необходимо.


Что думаете?


Подробная информация о списке рассылки devel-conf