Re: gconf2 на сервере
DIG wrote:
Доброе время суток, Sergey V. Spiridonov !
Sat, Jul 05, 2003 at 12:09:38AM +0200 Sergey V. Spiridonov написал(а):
Если параметры будут с ошибками (это будет возможно только если они
подготовлены вручную, скажем текстовым редактором, а не средством
конфигурации), то именно так дело и будет, ошибки будут обнаружены
только в момент импорта. Ну, впрочем для любителей подготовки параметров
вручную, можно сделать программу их проверки на основе констрэинтов в
базе данных жконф.
Мой основной вопрос был: как конфигуратор узнАет, что параметры ошибочны, а не просто -- необычны? (Неужели конфигуратор будет знать что-то о параметрах *лучше* самого приложения?)
Ну как же, я думал это понятно? Конфигуратор же знает имена параметров,
их типы. Насколько я знаю, сейчас нет, но в будущем появится возможность
писать сложные функции проверки, на каком-либо скриптовом языке, типа
гуиле. Без языка возможны только простые проверки, типа проверки на
принадлежность диапазону значений, но даже это лучше чем то что
предоставляет текстовый редактор. С текстовым редактором у нас нет даже
элементарной проверки синтаксиса.
Иногда некоторые приложения пытаются решить эту проблему, создавая
отдельную программу для проверки конфигурационного файла :), но в
большинстве случаев этого нет. Но в случае, если необходимость в такой
программе будет, библиотека жконф облегчит и эту задачу (простейшие и
синтаксические проверки сделает сам жконф, программе останется лишь
проверить сами значения). Но я считаю, что при наличие языка, на котором
можно будет писать проверки, необходимость в таких программах будет
возникать редко. Но это всё мои пожелания, сейчас, значения возвращаемые
жконф в программу я вляются "untrusted" и должны проверяться приложением
на соответствие типу.
Другой вопрос, откуда конфигуратор знает о параметрах. Ответ здесь тоже
простой - приложение ему скажет при инсталляции. То есть не разработчики
конфигуратора будут вносить имена типы и ограничения параметров для
приложения "А" в базу данных, а само приложение в процессе установки.
SVS> За редким исключением, максимум что может сделать приложение -
SVS> перечитать конфигурационный файл получив каким-то образом оповещение,
SVS> которое обычно посылается пользователем.
И это правильно.
Нет.
Аргументы?
Да, хотелось бы услышать аргументы, почему вы считаете что это правильно?
(1) Попробую НЕ отвечать вопросом на вопрос.
(2) Короткий ответ такой: я склонен считать, что решение принимает человек.
То есть, если мне захочется, чтобы Апачи перечитал конфиг-файл (который я поправил), то я ему (Апачи) так прямо об этом и скажу: перечитай, мол. Или же я решу, что перечитыванием параметров он у меня займётся ночью -- тогда же, когда logrotate будет его restart'ить. Это я решаю, а не конфигуратор. Потому что не конфигуратор, а я знаю -- когда Апачи должен перечитывать свои конфиги.
Или конфигуратор придётся делать очень "жирный", чтобы он и такие случаи мог бы обрабатывать.
Проблемы здесь просто нет. Когда я говорил что данная схема
"неправильна", я имел в виду, что с жконф возможна большая гибкость для
всех приложений которые его используют. Не конфигуратор решает, когда
Апачи узнает об изменениях, а пользователь, который эти изменения вносит.
Такой проблемы, как вы её описали, для жконф просто нет. Как будет
работать приложение с базой данной жконф, будет ли оно запрашивать
оповещение об изменениях или нет, когда и как оно будет читать новые
параметры, решает разработчик приложения. По моему мнению, если
изменения внесены в конфигурационный файл, приложение должно сразу
отреагировать на изменения, иначе появляется несоответствие между
содержанием файла и состоянием приложения. Если уж очень надо отложить
изменения, то нужно подготовить список изменяемых значений *не* в
рабочей конфигурационном файле, а в отдельном, новом файле. Ну это всё
входит в понятие "транзакция", которое необходимо ещё для других
случаев, однако на данном этапе развития жконф говорить о таком уровне
ещё рановато.
[snip]
Типа, _мои_ комментарии будет сохранять? Чтобы я мог вспомнить --
зачем я здесь *именно такое* значение параметра выставил? Очень
интересно...
Ах, вот о чём речь. Не, этого пока нет... Но почему бы и не сделать,
если это действительно кому-то нужно? Технически никакой проблемы здесь нет.
Ещё много чего много кому *действительно* нужно. Мне, например, иногда хочется rcsdiff между разными версиями посмотреть. Или, скажем, rlog -h -- если до этого не поленился кратенькое объяснение накарябать. Или посмотреть результат такого выражения:
$ rcsdiff -r"почти-всё-работает" -r"всё-работает" /etc/my-config
а потом -- такого:
$ rcsdiff -r"всё-работает" /etc/my-config
Или показать
$ rcsdiff -r1.1 -r"всё-работает" /etc/my-config
тому, кто спрашивает "А как это настроить ?".
Думаю, что основная мысль понятна.
Да, понятно, что ж не понятно? Историю изменений приятно иметь для
некоторых важных конфигурационных файлов. Кто же спорит? Жконф к этому
таки отношение мало имеет, это уже проблемы бакэнда, я думаю. Но мысль
ясна.
За редким исключением, максимум что может сделать приложение -
перечитать конфигурационный файл получив каким-то образом оповещение,
которое обычно посылается пользователем.
Добавим: ... и прочитает оно (приложение) _свой_ конфигурационный
файл именно тогда, когда (1) пользователь ему скажет это сделать,
либо (2) -- когда приложение "увидит", что конфигурационный
файл был изменён.
Да, именно так.
И это правильно. Я меняю параметры тогда, когда мне это кажется правильным. И я сообщаю об этих изменениях тогда, когда я считаю нужным это сделать.
Тоже справедливо и для подхода жконф, но в отличие от указанного выше
подхода (наилучшим из того что мы имеем сегодня), конфигурационный файл
и состояние приложения остаются синхронизированными.
Я обращаю ваше внимание на то, что конфигурационный файл и состояние
приложения могут не соответствовать друг другу. Впрочем, большинство
приложений сегодня, способно прочитать настройки из файла один раз, при
старте. Так что даже если Вы очень хотите, максимиум что Вы можете
сделать - перезапустить приложение.
А вот какие есть аргументы в пользу того, что конфигуратор лучше знает -- когда оповещать приложение о внесённых изменениях? Или он будет уметь это делать тогда, когда мне этого захочется?
Ну конечно.
1. Пользователю не нужно посылать никаких сигналов, если он изменяет
параметры с помощью приложения работающего с жконф (например
стандартным конфигуратором), или ему нужно послать сигнад жконф если он
менял настройки вручную (например прямо в базе данных, если в качестве
бакэнда использовался mysql).
Менять настройки и вынуждать приложение с ними считаться -- это
разные занятия.
Это действительно разные занятия. И что?
Очевидно что -- вопрос: в конфигуратор эта мысль заложена?
В общем, остаётся несколько вопросов:
(1) откуда конфигуратор будет знать о том, ошибочен параметр или просто необычен?
я надеюсь, что выше ответил на этот вопрос, как смог.
(2) откуда конфигуратор будет знать о том, когда и почему новые параметры должны вступить в силу?
Жконф не может решать эти вопросы, он может занести данные, которые ему
дают в базу данных, и оповестить тех, кто попросил их оповестить, что
данные изменены.
(3) кто будет конфигурировать конфигуратор?
;) текстовый файл старого образца, очевидно
Примите и пр.
Reply to: