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

[Denis Medvedev]

посмотрите вот это, пожалуйста
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