Доброе время суток, 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
