Нам так много не надо. ini вполне хватит. А их идея со значимым отступами мне вообще кажется ужасной ;)
31.10.07, Denis Medvedev<[EMAIL PROTECTED]> написал(а): > посмотрите вот это, пожалуйста > 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 _______________________________________________ devel-conf mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/devel-conf
