[Devel-conf] Metalterator

Pavel Wolneykien manowar на altlinux.org
Чт Апр 9 16:07:57 MSD 2009


Mykola S. Grechukh <nick.grechukh на gmail.com> wrote:

> 2009/4/9 Michael Shigorin <>:
> > On Wed, Apr 08, 2009 at 11:58:42PM +0400, QA Team Robot wrote:
> >> metalterator - Alterator meta-backend with additional Guile modules
> >> * Wed Apr 08 2009 Paul Wolneykien <manowar на altlinux> 1.0-alt1
> >> - Initial release.
> >
> > Расскажете подробнее?  На http://www.altlinux.org/Alterator
> > и в окрестностях ничего не нашёл, а интересно.

  Это радует, что интересно. ;)

> 
> description at http://tinyurl.com/d3x4ar  ?

  Да, окромя аннотации к пакету ничего пока нету. :)
  Но если дело пойдёт, то и документация обязательно появится.

  Значит дело было так. Собрался я писать модуль для Squid (во второй
раз, но это отдельная история). После разговора с wart@ и ldv@ мне стало
совершенно понятно, что для работы с относительно сложным
конфигурационным файлом нужна БД: ни читать, ни писать отдельные
значения в файл нельзя -- всё перепутается. Зато сгенерировать такой
файл целиком задача на порядок проще.

  Тогда я стал думать: какую БД мне выбрать? Ясно что самую простую,
поскольку данных, которыми может управлять пользователь в пределах
одного модуля, скорее всего, немного. Поэтому критерием поиска БД стало
удобство отображения в неё объектов Альтератора. И вот тут я понял, что
неплохим хранилищем для этих объектов будет обычная файловая система! На
что inger@ сказал: "ФС -- это одна из самых клёвых встроенных БД!".

 Ясно, что для отображения объектов в ФС нужен был отдельный набор
функций. Начав выдумывать сигнатуры функций я заметил, что базовый набор
повторяет woo-команды woo-read, woo-write, woo-new и woo-delete. Тогда я
решил, что было бы интересно напрямую подключить БД к шине
Woo-bus. Таким образом, вместо библиотеки я решил написать отдельный
бакенд, который бы отображал woo-команды на файловую систему.

  Конечно же работа модуля конфигуратора зачастую не исчерпывается
чтением и записью состояний объектов, но кто сказал, что бакенды не
могут выстраиваться в цепочки? Внутри Альтератора есть прямой доступ к
шине, а внешние бакенды могут использовать команду alterator-cmdline.
Так что идея мне показалась не такой уж плохой и я взялся за её
реализацию. Образ бакенда, использующего другой бакенд для
операций более низкого уровня, дал термин "метабакенд" или
"бакенд-для-бакенда". Название пакета "metalterator" было выбрано вместо
alterator-meta как обладающее более интересным, неоднозначным прочтением.

  На сегодняшний день (ему уже 2 дня) metalterator умеет отображать на
ФС как стандартные woo-команды "read", "write", "list", "new" и
"delete", так и парочку специальных: "link" и "read-next". Первая
создаёт ссылку на объект, путь до которого указано в параметре
"name". Ссылки на несуществующие объекты удаляются при попытке их
прочитать, поэтому есть кое-какая ссылочная целостность. Вторая команда
позволяет прочесть указанные атрибуты объекта с одновременным их
увеличением на 1, что удобно для генерации идентификаторов.

  Из интересных свойств можно отметить отображение имён параметров при
чтении, и режим отладки.

  Отображение имён включается если в команде на чтение данных ("read"
или "list") был указан один или несколько параметров. Сначала я думал
использовать их только для выбора атрибутов объекта, сообщаемых в
ответе. Но, поскольку в woo-команде нельзя перечислить имена параметров
не сообщив их значений, то я решил что незачем этим значениям зря
пропадать: теперь значения параметров запроса на чтение являются именами
параметров ответа. Если была дана команда прочесть атрибут, который не
задан в объекте, то будет явно возвращено значение #f. Для чтения всех
атрибутов достаточно опустить список параметров в запросе "read". Запрос
"list", наоборот, по умолчанию вернёт только имена объектов, а для
выполнения дополнительных операций по чтению атрибутов об этом нужно
явно сообщить, перечислив интересующие имена. Отображение имён, в этом
случае, позволяет сразу же адаптировать ответы метабакенда для их
передачи во фронтенд: например, "list" 'comment "label" позволит сразу
же получить набор объектов (("obj1" label "val1") ("obj2" label
"val2")...) из набора объектов (("obj1" comment "val1") ("obj2" comment
"val2")...).

  Режим отладки включается записью положительного значения в атрибут
корневого объекта метабакенда:

  alterator-cmdline /meta "write" debug-level 5

установит максимальный уровень детализации отладочных сообщений.

  Да, совсем забыл: полное имя объекта, т.е. всё, что идёт после /meta
интерпретируется как путь месту в ФС! К примеру,

  alterator-cmdline /meta/etc/metalterator/squid/squid "write" http_port "3128"

обновит значение http_port в файле /etc/metalterator/squid/squid.scm.

  В настоящее время единственным пользователем метабакенда является
бакенд squid из пакета alterator-squid-1.0-alt1. Кстати сказать:
конфигурацию по умолчанию этот пакет несёт с собой в виде набора файлов,
которые он кладёт как есть прямо в /etc/metalterator/squid. По моему это
тоже очень удобно!

  Для адаптации ответов метабакенда (отрезания имени пославшего ответ
объекта) существует макрос meta, определённый в модуле (alterator
metalterator). 

  Павел.


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