Re: gconf2 на сервере
Oleg Gritsinevich wrote:
On Mon, Jul 07, 2003 at 01:48:21PM +0200, Sergey V. Spiridonov wrote:
Oleg Gritsinevich wrote:
On Fri, Jul 04, 2003 at 12:35:20PM +0200, Sergey V. Spiridonov wrote:
[skip]
4. При всём при этом, остаётся возможность выбора бакэнда(формата) и
возможность сетевого взаимодействия, без необходимости что-либо
специально для этого программировать или изменять в приложении.
Как в концепцию gconf-а вписывается конфиг sendmail-а
(представляющий собой исходник на сноболе)?
Да хоть на фортране. Какая разница? В чём Вы здесь видите проблему?
Концепция жконфа вписывается так же, как TCP/IP вписывается в python, к
примеру.
Есть библиотека sockets, и есть к ней API на питоне. Точно так же есть
библиотека gconf а для остальных языков пишется соответствующее API.
Или я Вас не понял?
Речь идёт не о биндингах к API gconf-a другого языка, а о другом.
В данном случае _сам_ _конфиг_ (sendmail.cf) представляет собой
программу на некотором языке, которую интерпретирует другая программа (в
данном случае sendmail). Данный конфиг не вписывается в концепцию
name-value pair и ни в какой другой "общий формат" описания конфига тоже не
вписывается. Единственное, чем sendmail может воспользоваться в API
gconf-a, IMHO нотификация об изменении конфига, и чем это лучше обычного
kill -HUP?
При такой постановке, конечно, толку от gconf мало.
Я сам не знаком с внутренностями sendmail, хотя устанавливать и
настраивать его пару раз приходилось. То что я помню, это текст, который
сперва прогоняется через макропроцессор m4, а что потом с ним делается,
я даже не интересовался.
Так что квалифицированного ответа не ждите, но кое-какие соображения я
выскажу.
1. Жконф работает с "параметрами конфигурации". Называть текст
интерпретируемой программы, даже если она может быть изменена
пользователем, конфигурационным параметром конечно можно, но
революционного смысла, потрясающего основы основ, как Вы правильно
заметили, в этом особого нет.
Но то что указанный текст представляет собой интерпретируемую программу
не значит что *внутри* неё не используются конфигурационные параметры.
Внутри этого конфигурационного файла, как я помню, были значения
(придумываю на ходу), типа smarthostname("gnu.org").
Так вот этот smarthostname и может быть конфигурационным параметром,
хранимым в жконф.
2. Осмелюсь заявить, что такие программы как Sendmail это всё же скорее
исключение, чем правило. И сложность изучения его языка кофнигурирования
относится к разряду "общепризнанных" фактов.
Завязывание программы на gconf автоматически сужает её область
применения/распространения, по крайней мере системные вещи на него
завязываться не должны и скорее всего не будут.
Вы конечно в праве так полагать. Я надеюсь, вы основываетесь не только
на "сложности" конфигурирования Сендмэил?
Не совсем понятна цель создания gcnof-a:
- избавить программистов от рутинной писанины парсеров конфигов? В сложных
случаях, как в примере с sendmail-ом, это невозможно.
Сложность этого случая, насколько я могу судить на основе моего
скромного опыта использования не исключает возможность применения жконф,
как я указал выше. Кроме того, сложность обуславливается в большей
степени сложностью самого языка, а не конфигурации как таковой.
- предоставить средства редактирования конфигов с валидацией синтаксиса и
введённых значений? Ну синтаксис ещё можно кое-как отслеживать. Так
большинство существующих программ и так не запустятся с ошибкой конфиге.
Да, однако есть отличие между "не запустится" и невозможностью
синтаксической ошибки. В случае проверки типа, мы гарантируем, что
синтаксис (на описанном уровне, конечно), правилен.
Проверка семантики? Она тоже возможна только в самом примитивном виде
(проверка принадлежности значения к.-л. м-ву), а как н.п. проверить не
попутал ли пользователь наружный интерфейс с внутренним в конфиге iptables?
Если я Вас правильно понял, то в случае если пользователь попутал, то
этого не заметит даже iptables?
Конфигурирование сложных приложений gconf упростить не сможет, а в
простых случаях ничего упрощать и не надо.
Ни первое ни второе утверждение для меня, как для программиста,
пользователя и порой администратора не очевидно. По крайней мере на
основе приведенных примеров.
Даже если в сендмэил было бы невозможно использовать жконф, я бы не стал
ставить крест на этой идее. Кроме сендмэил, в Дебиане есть ещё 10000
пакетов.
IMHO работать оно будет только в простых случаях, а для простых
случаев достаточно иметь библиотеку парсилки конфига (н.п. вида name-value
pairs): на входе имя файла, на выходе представление конфига в виде
списка/дерева и т.п., подсовываешь библиотеке ключ -- получаешь значение
Ну, это именно то что сейчас есть, плюс оповещения и сетевая поддержка.
параметра. Семантической проверкой вообще никак не заниматься --
пользователь перед началом конфигурирования должен внимателььно прочесть
док-цию и иметь ясное представление о том, чего он хочет добиться в
конечном итоге.
Если есть возможность улучшить проверку, то зачем от неё отказываться?
Возможность дополнительной проверки на стороне сервера это
*возможность*. Вовсе необзательно её использовать там, где она не нужна.
Но всё же самое главное значение в жконфе имеет не проверки и не
оповещения, не возможность иметь различные бакэнды и даже не сетевое
взаимодействие.
Главное это стандартизация АПИ.
Что там будет творится после вызова get_bool("/sendmail/smarthost") это
конечно тоже важно. Но стандартизация АПИ является основным плюсом.
--
Best regards, Sergey Spiridonov
Reply to: