Доброе время суток, Sergey V. Spiridonov !
Sat, Jul 05, 2003 at 12:09:38AM +0200 Sergey V. Spiridonov написал(а):
> Если параметры будут с ошибками (это будет возможно только если они
> подготовлены вручную, скажем текстовым редактором, а не средством
> конфигурации), то именно так дело и будет, ошибки будут обнаружены
> только в момент импорта. Ну, впрочем для любителей подготовки параметров
> вручную, можно сделать программу их проверки на основе констрэинтов в
> базе данных жконф.
Мой основной вопрос был: как конфигуратор узнАет, что параметры ошибочны, а не
просто -- необычны? (Неужели конфигуратор будет знать что-то о параметрах
*лучше* самого приложения?)
> >>> SVS> За редким исключением, максимум что может сделать приложение -
> >>> SVS> перечитать конфигурационный файл получив каким-то образом оповещение,
> >>> SVS> которое обычно посылается пользователем.
> >>>И это правильно.
> >>
> >>Нет.
> >
> > Аргументы?
>
> Да, хотелось бы услышать аргументы, почему вы считаете что это правильно?
(1) Попробую НЕ отвечать вопросом на вопрос.
(2) Короткий ответ такой: я склонен считать, что решение принимает человек.
То есть, если мне захочется, чтобы Апачи перечитал конфиг-файл (который я
поправил), то я ему (Апачи) так прямо об этом и скажу: перечитай, мол. Или же я
решу, что перечитыванием параметров он у меня займётся ночью -- тогда же, когда
logrotate будет его restart'ить. Это я решаю, а не конфигуратор. Потому что не
конфигуратор, а я знаю -- когда Апачи должен перечитывать свои конфиги.
Или конфигуратор придётся делать очень "жирный", чтобы он и такие случаи мог бы
обрабатывать.
Sat, Jul 05, 2003 at 12:21:20AM +0200 Sergey V. Spiridonov написал(а):
> DIG wrote:
> > Доброе время суток, Sergey V. Spiridonov !
> >
> > Fri, Jul 04, 2003 at 12:35:20PM +0200 Sergey V. Spiridonov написал(а):
> >
> >
> >>Alexander Danilov wrote:
> >>[snip]
> >>
> >>>Пока проблема комментариев не будет решена в надстройках,
> >>>предназначенных для конфигурирования, я буду голосовать за vim :)
> >>
> >>Решена она, насколько я знаю. Есть подсказки и описания.
> >
> > Типа, _мои_ комментарии будет сохранять? Чтобы я мог вспомнить --
> > зачем я здесь *именно такое* значение параметра выставил? Очень
> > интересно...
>
> Ах, вот о чём речь. Не, этого пока нет... Но почему бы и не сделать,
> если это действительно кому-то нужно? Технически никакой проблемы здесь нет.
Ещё много чего много кому *действительно* нужно. Мне, например, иногда хочется
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) кто будет конфигурировать конфигуратор?
Примите и пр.
--
DIG (Dmitri I GOULIAEV)
1024D/63A6C649: 26A0 E4D5 AB3F C2D4 0112 66CD 4343 C0AF 63A6 C649
