Re: gconf2 на сервере
Dmitry Astapov wrote:
Для такого, нужно подготовить скрипт или файл с изменениями и
импортировать его завтра. И тогда затра приложение узнает об
изменениях.
... или об ошибке?
[snip]
Это если ошибки будут синтаксические или простые семантические (не
прошедшие валидацию). А если я вместо mx1.domen.org написал mx2.domen.org и
отгреб non-existing host/domain, то на такие ошибки валидаторов не
напасешься.
Да, с такими ошибками, не запустив приложение и не разберёшься. Тогда
Ваше утверждение выше безусловно верно. Эти ошибки касаются, конечно
самого подхода "изменить конфигурацию завтра", а не подхода жконф.
Безусловно, пользователь должен быть уверен, что его конфигурация не
содержит "сложных семантических" ошибок. Это возможно если он или кто-то
уже проверил эту конфигурацию на практике.
SVS> За редким исключением, максимум что может сделать приложение -
SVS> перечитать конфигурационный файл получив каким-то образом оповещение,
SVS> которое обычно посылается пользователем.
И это правильно.
Нет.
Аргументы?
SVS> Да, хотелось бы услышать аргументы, почему вы считаете что это
SVS> правильно?
Потому как человек своей головой уже подумал и решил, когда именно он хочет
применить настройки. И это надо сделать именно тогда, когда надо человеку,
а не когда у программы зачесалась левая пятка. Потому как есть scheduled
maintenance downtimes и все такое прочее ...
Я с Вами полностью согласен, и жконф никак не запрещает/отрицает
необходимость того что Вы написали.
Здесь просто возникло непонимание. Существуют различные области и
ситуации применения, в которых может потребоваться либо "мгновенная"
реакция на изменения конфигурации, либо "отложенная".
"отложенная" реакция чаще необходима для системных сервисов, а
"мгновенная" чаще для интерактивных приложений. Но я не исключаю
существование прямо противоположных ситуаций, с теми же приложениями.
Приведу пример для "мгновенной" реакции, первым пришедшим в голову
(может не очень удачный): стоит Апачи, и в один прекрасный момент мы
захотели изменить ограничение на количество одновременно запущенных
процессов Апачи, в этом случае, жконф обеспечит проверку нового значения
и оповестит Апачи о том что этот параметр изменился. Апачи запустит пару
новых процессов.
В большом ответе DIG (Dmitri I GOULIAEV) я написал, что с подходом жконф
возможны оба подхода. Для "отложенной" реакции это "экспорт"/"импорт" и
профили. То есть пользователь может использовать профили, или
экпортированную конфигурацию для того чтобы переключить приложение на
новую конфигурацию.
Моё "нет" означает несогласие с существующим подходом, когда
1. "Мгновенная" реакция просто невозможна. Идея жконф делает возможным
*оба* подхода.
2. Есть риск возникновения ситуации когда есть новый конфигурационный
файл на диске и приложение, работающее со старым конфигурационным файлом.
3. Во многих случаях приложение нужно именно перезапустить.
4. Проверка в большинстве случаев делается только на этапе запуска
приложения.
--
Best regards, Sergey Spiridonov
Reply to: