Re: gconf2 на сервере
DIG wrote:
То есть, всех гнать в гуиль? А если ч-к привык к Tcl, то ему никак не выжить?
Речь о том чтобы создать стандарт для хранения, извлечения, поиска и
оповещения конфигурационных параметров. Например такой каким является
SQL (пример на стандарт языка запросов RDBMS) или TCP/IP (набор
протоколов и C - интрефейс к ним), libc.
Никто никого не гнал в SQL. Этослучилось само собой. Хочешь
воспользоваться преимуществами стандартизации - используй стандартный
язык SQL. Не хочешь - пиши работу с базой данных хоть на tcl хоть на C.
Гуиль я написал, так как я к нему не равнодушен и он изначально
разрабатывался как встроенный язык и средство расширения приложений. Это
всего лишь одна из возможностей, возможно на чей то взгляд и не самая
лучшая.
А теперь -- более понятный пример: у меня есть приложениена Python'е. Конфигурационный файл этого приложения -- python'овский скрипт. Часть параметров (и логики) приложение получает из этого конфиг-файла. Есть также параметры, устанавливаемые после запуска программы (и которые зависят от окружения).
Вопрос: каким боком мне здесь гуиль? И как конфигураторбудет проверять правильность синтаксиса моего конфига? И, вдогонку: даже если конфигуратор можно научить делать такие сложные проверки, зачем *мне* это нужно?
Во-первых, я написал, что гуиль будет исполнятся на стороне сервера, то
программа на питоне не должна будет интерпретировать гуиль-скрипт.
Во-вторых в данном примере, скрипт на питоне это всего лишь часть
программы, которая может быть модифицирована пользователем.
Так вот, в данном случае, программист питона сможет воспользоваться
стандатрным интрефейсом к серверу конфигурации жконф для хранения,
поиска и извлечения параметров. Точно так же как он например может
воспользоваться SQL и ODBS для доступа к базе данных, или TCP/IP и
библиотеку сокетов для обмена данными по сети.
Конфигуратор будет проверять не правильность скрипта на питоне, а
правильность параметров, которые записываются на сервер. И на гуиле (к
примеру) можно будет написать дополнительные ограничения для проверки
значений на стороне сервера.
Иногда некоторые приложения пытаются решить эту проблему, создавая
отдельную программу для проверки конфигурационного файла :), но в
большинстве случаев этогонет. Но в случае, если необходимость в такой
программе будет, библиотека жконф облегчит и эту задачу (простейшие и
синтаксические проверки сделает сам жконф, программеостанется лишь
проверить сами значения). Но я считаю, что при наличие языка, на котором
можно будет писать проверки, необходимость в таких программах будет
возникать редко.
А аргументы?
Пока я вижу только то, что такие проверки можно будет писать на встроенном в конфигуратор языке. Я пока не вижу -- почему это лучше.
Лучше чем что? Сегодня проверки просто нет. Ну нет её. Например я
редактирую файл настройки апачи, какая при этом выполняется проверка?
НИКАКАЯ.
Даже без языка проверки на стороне сервера, простейшие проверки *уже*
выполняются. Например, еслипараметр число, то кроме числа ничего в базу
данных занести невозможно не залезая прямо туда "ручками".
Но это всё мои пожелания, сейчас, значения возвращаемые
жконф в программу я вляются"untrusted" и должны проверяться приложением
на соответствие типу.
Другой вопрос, откуда конфигуратор знает о параметрах.Ответ здесь тоже
простой - приложение ему скажет при инсталляции. То есть не разработчики
конфигуратора будут вносить имена типы и ограниченияпараметров для
приложения "А" в базу данных, а само приложение в процессе установки.
Ага. Сначала -- напиши приложение. А потом напиши ещё одно-- для конфигуратора. (Есть ещё один вариант -- не писать сложных приложений, но кто на него решится?)
Опять мимо. Не надо писать приложений для кофигуратора. Ну с чего Вы это
взяли? Если вы имеете в виду проверку значений параметров, то её надо
писать в любом случае, независимо от того где она будет выполняться. Моя
идея я в том, чтобы выполнятьпроверку как можно раньше - ещё на этапе
внесения параметра в конфигурационный файл.
Вы знакомы с базами данных? Сидеей констрэинтов, триггеров? Хорошем
стилем считается, когда целостность базы данных проверяется на стороне
же базы данных, а не на стороне клиента.
Тем не менее, проверка на стороне клиента не исключаетсяи не
запрещается. Если мне плевать на то что кто-то считает хорошим стилем, я
сделаю проверку на стороне клиента, и это будут только мои проблемы.
В данном случае, я говорю о *возможности* использования опыта
накопленного в области СУБДдля конфигурационных параметров. Никто не
будет заставлять писать программы красиво и пользоваться стандартами.
Я сильно сомневаюсь, что можно будет заставить программера делать одну и ту же проверку дважды: один раз делая проверку для конфигуратора, а второй -- внутри программы.
Не надо её делать дважды.
SVS> За редким исключением, максимум что может сделать приложение -
SVS> перечитать конфигурационный файл получив каким-то образом оповещение,
SVS> которое обычно посылается пользователем.
И это правильно.
Нет.
Аргументы?
Да, хотелось бы услышать аргументы, почему вы считаетечто это правильно?
(1) Попробую НЕ отвечать вопросом на вопрос.
(2) Короткий ответ такой: я склонен считать, что решение принимает человек.
То есть, если мне захочется, чтобы Апачи перечитал конфиг-файл (который я поправил),то я ему (Апачи) так прямо об этом и скажу: перечитай, мол.Или же я решу, что перечитыванием параметров он у меня займётся ночью -- тогда же, когда logrotate будет его restart'ить. Это ярешаю, а не конфигуратор. Потому что не конфигуратор, а язнаю -- когда Апачи должен перечитывать свои конфиги.
Или конфигуратор придётсяделать очень "жирный", чтобыон и такие случаи мог бы обрабатывать.
Проблемы здесь просто нет. Когда я говорил что данная схема
"неправильна", я имел в виду,что с жконф возможна большая гибкость для
всех приложений которые его используют. Не конфигуратор решает, когда
Апачи узнает об изменениях, а пользователь, который этиизменения вносит.
То есть -- пользователь таки"дёргает" Апачи или нет? Я внёс изменения в конфиг Апачи. Апачи подписан на уведомление от gconf'а о том, что в параметры были внесены изменения. Вопрос: Апачи побежит за новыми параметрами? Или будет ждать от меня специального сигнала? Если первое (то есть побежит) -- то каким образом "не конфигуратор решает, когда Апачи узнает об изменениях,а пользователь, который этиизменения вносит"? И если мне для "отложенного оповещения" надо будет хранить новыенастройки в файле -- то зачеммне gconf? А если второе (Апачи будет ждать специального сигнала, чтобы перечитать параметры) -- то зачем нужна подписка на уведомление? Я ему (Апачи) шепну, что пора читать -- он и так перечитает, несмотря на то -- старые параметры или не очень.
В том случае, как вы его описали, Апачи получит уведомление о
изменившихся параметрах когда пользователь попросит жконф об этом.
Тут возможны варианты:
1. Пользователь будет использовать для редактирования параметров
специальную утилиту, к примеру gconf-edit. В этом случае Апачи получит
уведомление когда пользователь нажмёт кнопку ОК. Пока пользователь не
нажмёт кнопку ОК, Апачи не будет уведомлён, а изменения не будут внесены
в базу данных.
Вопрос с отложенными параметрами решается тоже очень просто - вместо
кнопки ОК, может быть кнопка - "экспорт".
Другой вариант - использование профилей. Пользователь создаёт новый
профиль и когда ему нужно переключится на новый профиль, даёт одну
команду, "переключить апачи на профиль блабла".
2. Пользователь редактирует конфигурационные параметрамы "ручками".
В этом случае он должен будет послать оповещению жконфд, о том что он
изменил параметры.
[snip]
А зачем тогда подписка на уведомление об изменениях параметров, если читать новыепараметры приложение будеттолько после получения специального сигнала? Оно, приложение, разве после прочитывания параметров, не будет знать -- новые они или старые? Да и какая ему, собственно, разница? Ему же сказали "читать", значит -- будет читать. Новые ли, старые -- уже не важно.
Если приложение работает *только* по старой схеме (перечитывание
параметров по сигналу), то подписка конечно не нужна.
По моему мнению, если
изменения внесены в конфигурационный файл, приложениедолжно сразу
отреагировать на изменения, иначе появляется несоответствие между
содержанием файла и состоянием приложения.
... и не важно -- какая логика работы с конфиг-файлом была заложена в программу её разработчиками? Или всех будем приводить к одной логике?
>
Изменение конфиг-файла может быть ведь только ЧАСТЬЮ комбинации условий, приводящих к перечитыванию конфига.
Я уважаю Ваше мнение. Тем не менее, очень часто наблюдается такой диалог:
- Мне нужно включить то-то и то-то. Я его включил, но почему-то не
работает.
- А приложение перезапустил (вариант: сигнал послал)?
- А...!!!
[snip]
Я знаю только один случай принудительного удаления комментариев -- дистрибутив надискете.
А я говорил что-то об *удалении* комментариев?
[snip]
Да, понятно, что ж не понятно? Историю изменений приятноиметь для
некоторых важных конфигурационных файлов. Кто же спорит? Жконф к этому
таки отношение мало имеет, это уже проблемы бакэнда, я думаю. Но мысль
ясна.
О чём и речь:
(1) к ведению истории изменений -- "отношение мало имеет";
Это же относится и к сегодняшнему подходу. К ведению истории изменений
имеет отношение CVS, например. При чём здесь жконф или апач?
Или у Вас Апач коммитит изменения в ЦВС сам?
(2) к правильности параметров -- его ещё для этого специально программировать надо (да и то -- не факт, что он, конфигуратор, будет лучше приложения понимать -- что делать с параметрами и логикой);
Как я уже писал, простейшие проверки (синтаксис, диапазон, тип) уже есть
и делаются автоматически.
Разделение на то кто лучше или хуже тут неуместно. Проверки пишет
программист. Тот же, что пишет приложение. Поэтому если он не может
написать проверки, то он их и не напишет. Идея в *переносе* проверки с
клиента на сервер.
(3) комментарии хранить -- пока не ясно, можно или нет (случай хранения комментариев в fake'овых именах параметров отбрасываем);
Насколько я знаю, пользовательские комментарии в сегодняшней версии
жконф не поддерживаются. Единственное, что можно сделать сегодня -
сделать специальный параметр для этого. Технической проблемы добавить, я
повторю, здесь нет.
Зато есть рид-онли комментарии(описания) параметров.
(4) "когда и как оно будет читать новые параметры, решает разработчик приложения" -- то есть gconf и здесь как бы не при чём.
Тогда в чём его роль?
Жконф предоставляет стандартный механизм и стандартный интерфейс. Будет
им пользоваться разработчик или нет - его дело.
[snip]
Оксюморон. Состояние приложения и конфигурационный файл -- это "две большие разницы". Конфиг-файл влияет на состояние приложения, но трудноэто назвать "синхронизацией".
Именно так и обстоит дело сегодня.
Есть приложение. Оно управляется своей внутренней логикой и параметрами. Часть этих параметров и логики можнозадать извне с помощью конфиг-файла (ничего особенного, просто удобный способ хранить взаимосвязанные настройки в одном месте). Приложение умеет само определять -- пора ли перечитывать конфиг, и/или даёт возможность пользователю явно влиять на это. Большинство файлов в etc -- текстовые. Значит, у пользователя есть возможность хранить историю изменений и прочие полезные мелочи.
Вопрос: с какого бока здесьgconf?
"Позвольте пойти с начала?" (С) :)
Я обращаю ваше внимание на то, что конфигурационный файл и состояние
приложения могут не соответствовать друг другу. Впрочем, большинство
приложений сегодня, способно прочитать настройки из файла один раз, при
старте. Так что даже если Выочень хотите, максимиум чтоВы можете
...............................^^^^^
Мы уже выяснили, что это всёотносительно.
сделать - перезапустить приложение.
Это определяется их (приложений) логикой работы с конфигом.
Это определяется приоритетами. Обычно конфигурирование это не
приоритетная задача при разработке.
А вот какие есть аргументыв пользу того, что конфигуратор лучше знает -- когда оповещать приложение о внесённых изменениях? Или он будет уметь это делать тогда, когда мне этого захочется?
Ну конечно.
Да? А поподробнее можно, разуж это так очевидно: какие есть (будут) возможности отложенного чтения конфигурационных параметров? И можно лииспользовать несколько вариантов конфигурации (типа разных конфигурационных файлов, которые можно указать вкомандной строке).
Приведу пример: у меня вечером (по crontab'у) aumix читает один файл, а утром -- другой. Что мне gconf может предложить?
См. пример выше с Апачи.
Итак,
(1) ревизии, разные варианты настройки (в зависимости отразных внешних обстоятельств) и комментарии -- "зависит от бэк-энда" (не очень, правда, понятно -- КАК это зависит; по-моему, это либо разрешено и поддержка реализована, либонет);
Я не говорил, что разные варианты настройки зависят от бакэнда. Есть
профили, есть экспорт-импорт.
Ревизии, в том виде котором Вы описали. Не имеют отношения к
кофнигурированию приложения.
Каким образом Апачи использует ревизии? Вы что?
Это дело сугубо администратора, хочет он иметь ревизии - он берёт
соответсвующий бакэнд (например ЦВС).
Хочет использовать преимущества БД - берёд майскьюэль.
Ему нужно ЛДАП - пожалуйста.
И это правильно. Не приложение решает, а администратор. В отличие от
сегодняшнего подхода.
(2) проверка правильности параметров: всех загнать в упрощённый синтаксис, расширяемый вставками на гуиле -- то есть, строго говоря, проверка(более-менее адекватная) отсутствует; хуже того: если проверку снаружи и проверку внутри закодировали по-разному -- будут сюрпризы... и они будут;
И что? Это хуже чем *полное* отсутствие проверки?
(3) конфигуратор может сообщить приложению, что параметры изменились, если приложение его об этом попросит;
да
остаётся вопрос -- кто скажет приложению, что пора спрашивать конфигуратор?
Вот для этого и сделаны оповещения, иначе остаётся старый подход.
Если же мы говорим о том, чтобы не ограничивать пользователя тем, что
приложение узнаёт о том, что параметры поменялись СРАЗУ, то придётся в
gconf вводить "отложенное оповещение". Чем это будет лучше "kill -HUP
..." сделанного с помощью ``at''?
Я уже изложил, как минимум *2* подхода к решению этой проблемы.
Вопрос: чем gconf *лучше*, чем комбинация "текстовый конфиг-файл + vi + rcs + unix" (unix в данном контексте -- это шелл и всё, что я могу в шелл сделать) ?
"Позвольте пойти с начала" ;) :) :D
Что ещё (кроме (а) "хранения параметров в БД" [непонятно пока -- зачем это нужно], (б) оповещение приложений, "кто попросил их оповестить", и (в) принудительной унификации описания параметров [что не всегда хорошо]) -- что ещё gconf может делать?
Главное здесь - сквозная стандартизация.
Стандартизация начиная с типов, форматов, проверок, и заканчивая
оповещением и API. Вот что главное.
Примите и пр.
^^^^^^^^^^
А что это значит?
--
Best regards, Sergey Spiridonov
Reply to: