посмотрите вот это, пожалуйста http://ru.wikipedia.org/wiki/YAML
-----Original Message----- From: "Stanislav Ievlev" <[EMAIL PROTECTED]> To: [email protected] 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 > [email protected] > https://lists.altlinux.org/mailman/listinfo/devel-conf _______________________________________________ devel-conf mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/devel-conf
