Mykola S. Grechukh <nick.grech...@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 <mano...@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 mailing list devel-conf@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/devel-conf
