>Да забудьте вы это слово "Registry". Важен сам подход - хранение cfg
>в формате, который удобен для разбора и составления программным способом а
>не вручную. Что касается дружелюбности к человеку. Если формат cfgdb будет
>единым как ASCII для текстовых конфигов, то для админа нет никакой
>разницы запускать текстовый редактор или какой-нибудь cfgedit.Если админ сможет остаточно просто и быстро изменить настройки программы, загрузившись с дискетки или подсунув HDD на другую машину, то особых проблем нет. Сейчас надежность инструмента гарантируется его простотой.
Кстати, есть и другой выход - компиляция тектового конфига в двоичный формат в т.ч. в БД, например, в Berkeley DB.
>Преимущества:
>1) программистам не нужно каждый раз изобретать формат своих текстовых конфигов со
>всякими способами как засунуть список в переменную, как экранировать специсимвол в
>значении (пробел, знак равно), как программе сказать, что 09 это строка
>символов а не число и т.д., они просто используют библиотеку для
>работы с cfgdb;
Даже на винде для работы с ini-шниками есть специальные функции в API. Двоичные данные можно хранить в HEX или в отдельном двоичном файле, например в БД.
В текстовых файлах нужно хранить настройки МИНИМАЛЬНО необходимые для запуска программы. Данные, которыми оперирует программа, изменяет их, нужно хранить в БД.
Может я чего не догоняю? Приведите пример для наглядности.
>2) при установке программы или её обновлением скрипт установки или менеджеры пакетов
>не будут ковыряться в конфигах sed'ом а будут использовать опять-таки библиотеку
>libcfgdb;
Тем не менее сейчас APT на Дебиане как-то справляется. Но я только "ЗА" буду обеими руками, когда появится API (хотя бы рекомендованный) для работы с текстовыми конфигами.
>3) программист программы получает возможность в схему встроить подсказки к параметрам, которые
>сейчас оформляют в виде кооментариев к конфигу-примеру и которые сильно замусоривают
>его, снижая наглядность а удалять их не всегда хочется - вдруг
>позже пригодится, эти подсказки можно сделать выдимыми в cfgedit;
1) Никто не мешает программисту сделать GUI для работы с конфигом.
2) Никто не мешает сделать админу конфиг только со своими настройками и без комментариев, сохранив копию оригинального файла. Часто свой конфиг при этом получается весьма кратким.
Обратите внимание как сделано в Mozilla Firefox/Thunderbird. Весьма простой GUI для редактирования настроек, только комментариев не хватает.
>4) для параметров, значения которых должны являтся членом какого-то множества (типа yes-no
>или low-medium-high или [1-2] и т.д.) cfgedit может выполнять проверку на
>ошибки ввода или даже давать выбор из списка и ничего более;
Это уже пользовательские рюшечки. Вполе достаточно сделать
someapp --check-config
до применения новых настроек.
>5) cfgedit может автоматически увеличивать номер версии cfgdb после каждого редактирования, вспомним
>файлы описания зон BIND'а и как многие забывают обновить номер версии
>после внесения изменений;
Чем это полезно для конфигов? Их нужно реплицировать?
>6) сетевые сервисы, которые динамически запускают и останавливают множественные экземпляры должны иметь
>постоянную возможность читать cfg - cfgdb можно редактировать без останова обслуживания
>и боязни сделать промежуточный нечитаемый cfg.
Читать нужно /etc, а писать в /var или /tmp
Приведите, плиз, пример, когда программа должна сама себе настройки менять.
