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

[Stanislav Ievlev]

Нам так много не надо. ini вполне хватит.
А их идея со значимым отступами мне вообще кажется ужасной ;)

31.10.07, Denis Medvedev<a_mdl на mail.ru> написал(а):
> посмотрите вот это, пожалуйста
> http://ru.wikipedia.org/wiki/YAML
>
> -----Original Message-----
> From: "Stanislav Ievlev" <stanislav.ievlev на gmail.com>
> To: devel-conf на lists.altlinux.org
> Date: Wed, 31 Oct 2007 12:25:02 +0300
> Subject: [Devel-conf] I: idl - окончательный вариант
>
> > Просмотрел множество существующих вариантов и ни один меня не устроил ;)
> >
> > 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 mailing list
> > devel-conf на lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel-conf
> _______________________________________________
> devel-conf mailing list
> devel-conf на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-conf