Re: gconf2 на сервере
Доброе время суток, Sergey V. Spiridonov !
Sat, Jul 05, 2003 at 12:35:22PM +0200 Sergey V. Spiridonov написал(а):
> DIG wrote:
> >
> > Sat, Jul 05, 2003 at 12:09:38AM +0200 Sergey V. Spiridonov написал(а):
> >
[...]
> >
> > Мой основной вопрос был: как конфигуратор узнАет, что параметры ошибочны, а не просто -- необычны? (Неужели конфигуратор будет знать что-то о параметрах *лучше* самого приложения?)
>
> Ну как же, я думал это понятно?
И продолжает оставаться непонятным. Потому что пока это не описано -- это не понятно.
> Конфигуратор же знает имена параметров,
> их типы. Насколько я знаю, сейчас нет, но в будущем появится возможность
> писать сложные функции проверки, на каком-либо скриптовом языке, типа
> гуиле. Без языка возможны только простые проверки, типа проверки на
> принадлежность диапазону значений, но даже это лучше чем то что
> предоставляет текстовый редактор. С текстовым редактором у нас нет даже
> элементарной проверки синтаксиса.
То есть, всех гнать в гуиль? А если ч-к привык к Tcl, то ему никак не выжить?
А теперь -- более понятный пример: у меня есть приложение на Python'е. Конфигурационный файл этого приложения -- python'овский скрипт. Часть параметров (и логики) приложение получает из этого конфиг-файла. Есть также параметры, устанавливаемые после запуска программы (и которые зависят от окружения).
Вопрос: каким боком мне здесь гуиль? И как конфигуратор будет проверять правильность синтаксиса моего конфига? И, вдогонку: даже если конфигуратор можно научить делать такие сложные проверки, зачем *мне* это нужно?
> Иногда некоторые приложения пытаются решить эту проблему, создавая
> отдельную программу для проверки конфигурационного файла :), но в
> большинстве случаев этого нет. Но в случае, если необходимость в такой
> программе будет, библиотека жконф облегчит и эту задачу (простейшие и
> синтаксические проверки сделает сам жконф, программе останется лишь
> проверить сами значения). Но я считаю, что при наличие языка, на котором
> можно будет писать проверки, необходимость в таких программах будет
> возникать редко.
А аргументы?
Пока я вижу только то, что такие проверки можно будет писать на встроенном в конфигуратор языке. Я пока не вижу -- почему это лучше.
> Но это всё мои пожелания, сейчас, значения возвращаемые
> жконф в программу я вляются "untrusted" и должны проверяться приложением
> на соответствие типу.
>
> Другой вопрос, откуда конфигуратор знает о параметрах. Ответ здесь тоже
> простой - приложение ему скажет при инсталляции. То есть не разработчики
> конфигуратора будут вносить имена типы и ограничения параметров для
> приложения "А" в базу данных, а само приложение в процессе установки.
Ага. Сначала -- напиши приложение. А потом напиши ещё одно -- для конфигуратора. (Есть ещё один вариант -- не писать сложных приложений, но кто на него решится?)
Я сильно сомневаюсь, что можно будет заставить программера делать одну и ту же проверку дважды: один раз делая проверку для конфигуратора, а второй -- внутри программы.
> >>>>>SVS> За редким исключением, максимум что может сделать приложение -
> >>>>>SVS> перечитать конфигурационный файл получив каким-то образом оповещение,
> >>>>>SVS> которое обычно посылается пользователем.
> >>>>>И это правильно.
> >>>>
> >>>>Нет.
> >>>
> >>>Аргументы?
> >>
> >>Да, хотелось бы услышать аргументы, почему вы считаете что это правильно?
> >
> > (1) Попробую НЕ отвечать вопросом на вопрос.
> > (2) Короткий ответ такой: я склонен считать, что решение принимает человек.
> >
> > То есть, если мне захочется, чтобы Апачи перечитал конфиг-файл (который я поправил), то я ему (Апачи) так прямо об этом и скажу: перечитай, мол. Или же я решу, что перечитыванием параметров он у меня займётся ночью -- тогда же, когда logrotate будет его restart'ить. Это я решаю, а не конфигуратор. Потому что не конфигуратор, а я знаю -- когда Апачи должен перечитывать свои конфиги.
> > Или конфигуратор придётся делать очень "жирный", чтобы он и такие случаи мог бы обрабатывать.
>
> Проблемы здесь просто нет. Когда я говорил что данная схема
> "неправильна", я имел в виду, что с жконф возможна большая гибкость для
> всех приложений которые его используют. Не конфигуратор решает, когда
> Апачи узнает об изменениях, а пользователь, который эти изменения вносит.
То есть -- пользователь таки "дёргает" Апачи или нет? Я внёс изменения в конфиг Апачи. Апачи подписан на уведомление от gconf'а о том, что в параметры были внесены изменения. Вопрос: Апачи побежит за новыми параметрами? Или будет ждать от меня специального сигнала? Если первое (то есть побежит) -- то каким образом "не конфигуратор решает, когда Апачи узнает об изменениях, а пользователь, который эти изменения вносит"? И если мне для "отложенного оповещения" надо будет хранить новые настройки в файле -- то зачем мне gconf? А если второе (Апачи будет ждать специального сигнала, чтобы перечитать параметры) -- то зачем нужна подписка на уведомление? Я ему (Апачи) шепну, что пора читать -- он и так перечитает, несмотря на то -- старые параметры или не очень.
> Такой проблемы, как вы её описали, для жконф просто нет. Как будет
> работать приложение с базой данной жконф, будет ли оно запрашивать
> оповещение об изменениях или нет, когда и как оно будет читать новые
> параметры, решает разработчик приложения.
А зачем тогда подписка на уведомление об изменениях параметров, если читать новые параметры приложение будет только после получения специального сигнала? Оно, приложение, разве после прочитывания параметров, не будет знать -- новые они или старые? Да и какая ему, собственно, разница? Ему же сказали "читать", значит -- будет читать. Новые ли, старые -- уже не важно.
> По моему мнению, если
> изменения внесены в конфигурационный файл, приложение должно сразу
> отреагировать на изменения, иначе появляется несоответствие между
> содержанием файла и состоянием приложения.
... и не важно -- какая логика работы с конфиг-файлом была заложена в программу её разработчиками? Или всех будем приводить к одной логике?
Изменение конфиг-файла может быть ведь только ЧАСТЬЮ комбинации условий, приводящих к перечитыванию конфига.
> Если уж очень надо отложить
.....................................................^^^^^
Кто ж его знает заранее -- очень или не очень?
> изменения, то нужно подготовить список изменяемых значений *не* в
> рабочей конфигурационном файле, а в отдельном, новом файле. Ну это всё
> входит в понятие "транзакция", которое необходимо ещё для других
> случаев, однако на данном этапе развития жконф говорить о таком уровне
> ещё рановато.
Если мне нужны какие-то ещё файлы -- то зачем мне gconf?
>
> [snip]
>
> >>>Типа, _мои_ комментарии будет сохранять? Чтобы я мог вспомнить --
> >>>зачем я здесь *именно такое* значение параметра выставил? Очень
> >>>интересно...
> >>
> >>Ах, вот о чём речь. Не, этого пока нет... Но почему бы и не сделать,
> >>если это действительно кому-то нужно? Технически никакой проблемы здесь нет.
А что, это может быть кому-то не нужно?
Я знаю только один случай принудительного удаления комментариев -- дистрибутив на дискете.
> > Ещё много чего много кому *действительно* нужно. Мне, например, иногда хочется rcsdiff между разными версиями посмотреть. Или, скажем, rlog -h -- если до этого не поленился кратенькое объяснение накарябать. Или посмотреть результат такого выражения:
> >
> > $ rcsdiff -r"почти-всё-работает" -r"всё-работает" /etc/my-config
> >
> > а потом -- такого:
> >
> > $ rcsdiff -r"всё-работает" /etc/my-config
> >
> > Или показать
> >
> > $ rcsdiff -r1.1 -r"всё-работает" /etc/my-config
> >
> > тому, кто спрашивает "А как это настроить ?".
> >
> > Думаю, что основная мысль понятна.
>
> Да, понятно, что ж не понятно? Историю изменений приятно иметь для
> некоторых важных конфигурационных файлов. Кто же спорит? Жконф к этому
> таки отношение мало имеет, это уже проблемы бакэнда, я думаю. Но мысль
> ясна.
О чём и речь:
(1) к ведению истории изменений -- "отношение мало имеет";
(2) к правильности параметров -- его ещё для этого специально программировать надо (да и то -- не факт, что он, конфигуратор, будет лучше приложения понимать -- что делать с параметрами и логикой);
(3) комментарии хранить -- пока не ясно, можно или нет (случай хранения комментариев в fake'овых именах параметров отбрасываем);
(4) "когда и как оно будет читать новые параметры, решает разработчик приложения" -- то есть gconf и здесь как бы не при чём.
Тогда в чём его роль?
> >>>>За редким исключением, максимум что может сделать приложение -
> >>>>перечитать конфигурационный файл получив каким-то образом оповещение,
> >>>>которое обычно посылается пользователем.
> >>>
> >>>Добавим: ... и прочитает оно (приложение) _свой_ конфигурационный
> >>>файл именно тогда, когда (1) пользователь ему скажет это сделать,
> >>>либо (2) -- когда приложение "увидит", что конфигурационный
> >>>файл был изменён.
> >>
> >>Да, именно так.
> >
> > И это правильно. Я меняю параметры тогда, когда мне это кажется правильным. И я сообщаю об этих изменениях тогда, когда я считаю нужным это сделать.
>
> Тоже справедливо и для подхода жконф, но в отличие от указанного выше
> подхода (наилучшим из того что мы имеем сегодня), конфигурационный файл
> и состояние приложения остаются синхронизированными.
Оксюморон. Состояние приложения и конфигурационный файл -- это "две большие разницы". Конфиг-файл влияет на состояние приложения, но трудно это назвать "синхронизацией".
Есть приложение. Оно управляется своей внутренней логикой и параметрами. Часть этих параметров и логики можно задать извне с помощью конфиг-файла (ничего особенного, просто удобный способ хранить взаимосвязанные настройки в одном месте). Приложение умеет само определять -- пора ли перечитывать конфиг, и/или даёт возможность пользователю явно влиять на это. Большинство файлов в etc -- текстовые. Значит, у пользователя есть возможность хранить историю изменений и прочие полезные мелочи.
Вопрос: с какого бока здесь gconf?
> Я обращаю ваше внимание на то, что конфигурационный файл и состояние
> приложения могут не соответствовать друг другу. Впрочем, большинство
> приложений сегодня, способно прочитать настройки из файла один раз, при
> старте. Так что даже если Вы очень хотите, максимиум что Вы можете
...............................^^^^^
Мы уже выяснили, что это всё относительно.
> сделать - перезапустить приложение.
Это определяется их (приложений) логикой работы с конфигом.
> > А вот какие есть аргументы в пользу того, что конфигуратор лучше знает -- когда оповещать приложение о внесённых изменениях? Или он будет уметь это делать тогда, когда мне этого захочется?
>
> Ну конечно.
Да? А поподробнее можно, раз уж это так очевидно: какие есть (будут) возможности отложенного чтения конфигурационных параметров? И можно ли использовать несколько вариантов конфигурации (типа разных конфигурационных файлов, которые можно указать в командной строке).
Приведу пример: у меня вечером (по crontab'у) aumix читает один файл, а утром -- другой. Что мне gconf может предложить?
> >>>>1. Пользователю не нужно посылать никаких сигналов, если он изменяет
> >>>>параметры с помощью приложения работающего с жконф (например
> >>>>стандартным конфигуратором), или ему нужно послать сигнад жконф если он
> >>>>менял настройки вручную (например прямо в базе данных, если в качестве
> >>>>бакэнда использовался mysql).
> >>>
> >>>Менять настройки и вынуждать приложение с ними считаться -- это
> >>>разные занятия.
> >>
> >>Это действительно разные занятия. И что?
> >
> > Очевидно что -- вопрос: в конфигуратор эта мысль заложена?
> >
> > В общем, остаётся несколько вопросов:
> > (1) откуда конфигуратор будет знать о том, ошибочен параметр или просто необычен?
>
> я надеюсь, что выше ответил на этот вопрос, как смог.
Простые параметры загнать в общий синтаксис, а сложные доверить гуилю? То есть, мне, кроме приложения, ещё надо на гуиле логику работы с конфиг-файлом программировать? И, я забыл: это мне интересно-заманчиво почему?
> > (2) откуда конфигуратор будет знать о том, когда и почему новые параметры должны вступить в силу?
>
> Жконф не может решать эти вопросы, он может занести данные, которые ему
> дают в базу данных, и оповестить тех, кто попросил их оповестить, что
> данные изменены.
БД, это, конечно, интересно... Но что будем делать с ревизиями? И с комментариями? А также -- с просто разными настройками (пример с aumix)?
> > (3) кто будет конфигурировать конфигуратор?
>
> ;) текстовый файл старого образца, очевидно
Эх! А так всё было задумано хорошо!.. А тут, нате вам -- опять текстовые файлы...
Итак,
(1) ревизии, разные варианты настройки (в зависимости от разных внешних обстоятельств) и комментарии -- "зависит от бэк-энда" (не очень, правда, понятно -- КАК это зависит; по-моему, это либо разрешено и поддержка реализована, либо нет);
(2) проверка правильности параметров: всех загнать в упрощённый синтаксис, расширяемый вставками на гуиле -- то есть, строго говоря, проверка (более-менее адекватная) отсутствует; хуже того: если проверку снаружи и проверку внутри закодировали по-разному -- будут сюрпризы... и они будут;
(3) конфигуратор может сообщить приложению, что параметры изменились, если приложение его об этом попросит; остаётся вопрос -- кто скажет приложению, что пора спрашивать конфигуратор? Если же мы говорим о том, чтобы не ограничивать пользователя тем, что приложение узнаёт о том, что параметры поменялись СРАЗУ, то придётся в gconf вводить "отложенное оповещение". Чем это будет лучше "kill -HUP ..." сделанного с помощью ``at''?
Вопрос: чем gconf *лучше*, чем комбинация "текстовый конфиг-файл + vi + rcs + unix" (unix в данном контексте -- это шелл и всё, что я могу в шелл сделать) ?
Что ещё (кроме (а) "хранения параметров в БД" [непонятно пока -- зачем это нужно], (б) оповещение приложений, "кто попросил их оповестить", и (в) принудительной унификации описания параметров [что не всегда хорошо]) -- что ещё gconf может делать?
Примите и пр.
--
DIG (Dmitri I GOULIAEV)
1024D/63A6C649: 26A0 E4D5 AB3F C2D4 0112 66CD 4343 C0AF 63A6 C649
Reply to: