Что придёт на смену xorg.conf?

>> Невозможно без поддержки со стороны конкретного приложения. Кто не согласен -- тот неправ

> Дядя - ты не в теме. Тебе еще раз сказали - если есть DTD конфига - то легко и непренужденно по нему сгенерировать конфигурялку. Да тут даже не о XML Говорят - тут о схемах GConf но суть та-же. Лично я только за.

Нет, это ты не в теме. Ни в какую схему нельзя засовать что-то более сложное, чем проверку по regexp. И потому эти схемы сосут.

. Та же самая проверка, которая будет проверять значение, все проверку на валидность формата возьмет на себя тот же gconf.

То есть будет две проверки: проверка похожести на нужное, затем логическая. Зашибись!

> Чтобы программистам не надо было изобретать велосипед каждый раз

Берём в качестве формата конфига стандартизованный язык программирования.

> или копаться в чужих велосипедах.

Копаться в чужом велосипеде всё равно придётся (или по Вашему, люди рождаются со знанием XML?), вопрос только в том, насколько он кривой. Так вот XML -- это самое неудобное и кривое, что можно только придумать.

> > Вы что, хотите, к примеру, чтоб postfix смог распрасить конфиг apache?

> Нафига б? Но я хочу иметь единый способ доступа к конфигам того и другого.

А он и так есть -- текстовый редактор.

> Чтоб тулзы типа webmin (а также всякого рода control panels) не были свалкой костылей.

Они по определению -- набор костылей.

> А еще чтобы можно было прозрачно менять локальную конфигурацию апача и постфикса - на ldap. Одним движением руки. Без перекомпиляции и переписывания этих приложений.

Напишите ФС на fuse, которая будет представлять ветку LDAP-дерева в виде набора конфигов. И не надо баек про производительность, тем более что в данном случае всё будет упираться в латентность сети и/или производительность LDAP сервера.

А что, у вас как-то по другому? тикль кода делает eval не делает формальную проверку на соответствие синтаксису? Или он каким-то образом узнает, что некий строковый параметр конфига должен быть именем хоста и с легкостью отличает "example.com" от "!$#$$^346456" ?

> Берём в качестве формата конфига стандартизованный язык программирования.

А потом радуемся тому, что этот Тюринг-полный конфиг становится головной болью с т.зр. безопасности.

> Копаться в чужом велосипеде всё равно придётся

В одном - можно. В сотне - не хочется.

> А он и так есть -- текстовый редактор.

Не надо передергивать. Я просил программный способ доступа. Причем в терминах конфигурации - а не в терминах строчек-байтиков.

> Они по определению -- набор костылей.

И виновата в этом помойка в /etc. При наличии единой архитектуры конфигурирования - определение поменяется.

> Напишите ФС на fuse, которая будет представлять ветку LDAP-дерева в виде набора конфигов.

Как Вы себе представляете реализацию операции записи в такой ФС? А вообще это опять-таки жутко велосипедное решение, к тому же с введением лишной сущности.

> Берём в качестве формата конфига стандартизованный язык программирования.

Это какой такой?

> А он и так есть -- текстовый редактор.

а программный доступ? или каждый раз городить костыли для всех конфигов, выходящих за рамки key=value?

>> высокоуровневого дизайна мегаредактора?

> Сорри, я пропустил вопрос. Где он? Или повторите плиз?

Как устроена(ну или должна быть в идеале устроена) с точки зрения High-level Design-а подобная программа для редактирования конфигурации? В частности, что там будет называться model, view, controller? А ещё более интересно, будет ли там контроллер статическим и работающим только на основе модели?

> А что, у вас как-то по другому? тикль кода делает eval не делает формальную проверку на соответствие синтаксису? Или он каким-то образом узнает, что некий строковый параметр конфига должен быть именем хоста и с легкостью отличает "example.com" от "!$#$$^346456" ?

По контексту, епть. Потому что я знаю в своей программе, что hostname у меня -- имя хоста :P

Моделью будет сама конфигурация. View и Controller строятся динамически на основе мета-информации об элементах конфигурации.

Как пример - посмотрите на то, как конфигурируется выбор раскладок и опций раскладок в гноме. Пример эстетически не самый удачный, должен признать - но исключительно в силу недостачи метаинформации.

Вот ты и получаешь две проверки - одно самим тиклем, вторую свою. В случае с gconf все останется точно так же, только первую проверку будет делать gconf на на основании неких общих правил, необходимых для обработки конфига определенного формата (совсем не обязательно xml, пусть хоть s-exp)

> А потом радуемся тому, что этот Тюринг-полный конфиг становится головной болью с т.зр. безопасности.

Опять натягиваем частный случай дырявого сендмейла на всех? Аяяй!

> Как Вы себе представляете реализацию операции записи в такой ФС?

::ldap::modify $handle $fileName $fileContent. Какая проблема?

> А вообще это опять-таки жутко велосипедное решение, к тому же с введением лишной сущности.

Я фигею в этом зоопарке: переписать все программы, держать в памяти gconfd -- это всё хорошо, а как написать одну фс -- так сразу лишняя сучность.

> Моделью будет сама конфигурация. View и Controller строятся динамически на основе мета-информации об элементах конфигурации.

Отлично, этого я и ждал.

Предлагаю рассказать мне, какая именно метаинформация нужна в модели, чтобы обеспечить нормальный гуй? Например, если опции "логин" и "пароль" имеют смысл только при опции "авторизация", выставленной в true.

> Вот ты и получаешь две проверки - одно самим тиклем, вторую свою.

Если считать и проверку от парсера, то у тебя получается их даже три: проверка синтаксиса хмл, проверка в gconf и проверка логики в программе. Причём 2 и 3 пункт тесно связаны логически, но разнесены по разным местам, что не Ъ.

> А потом радуемся тому, что этот Тюринг-полный конфиг становится головной болью с т.зр. безопасности.

Сделать больше, чем даст ОС, не выйдет. А всякий, кто верит, что можно достичь безопасности другими средствами, либо дурак, либо обманщик.

> Не надо передергивать. Я просил программный способ доступа. Причем в терминах конфигурации - а не в терминах строчек-байтиков.

Поглядите, как сделан sawfish-ui.

> Как Вы себе представляете реализацию операции записи в такой ФС?

А чего его представлять-то? http://www.ldapfs.org/

> А вообще это опять-таки жутко велосипедное решение,

Это как раз нормальное UNIX-way решение.

> к тому же с введением лишной сущности.

Лишние сущности -- XML и gconf, а не ФС.

>> Как Вы себе представляете реализацию операции записи в такой ФС?

> А чего его представлять-то? http://www.ldapfs.org/

Окинул беглым взглядом и создалось впечатление, что для конфигов она не очень-то предназначена.

>Поглядите, как сделан sawfish-ui.

лень на кладбище идти.

>А чего его представлять-то? http://www.ldapfs.org/

скажи честно - ты его смотрел хотя бы? Давай, на память - в каком году умерло и какие ограничения накладывает.

>Это как раз нормальное UNIX-way решение.

не надо превращать юникс-вей в набор костылей. Когда софт используется не для того, для чего он предназначен - это не юних-вей, а не знаю что

> Я фигею в этом зоопарке: переписать все программы, держать в памяти gconfd -- это всё хорошо, а как написать одну фс -- так сразу лишняя сучность.

Не обращайте внимания, тут у некоторых (не буду тыкать пальцем) очень хорошо развит doublethink.

> не надо превращать юникс-вей в набор костылей. Когда софт используется не для того, для чего он предназначен - это не юних-вей, а не знаю что

/me пошёл удалять файлы устройств из /dev и отмонтировать /proc и /sys, а то там костыли какие-то :о)

>В случае с gconf все останется точно так же, только первую проверку будет делать gconf на на основании неких общих правил

если не секрет, откуда их взять, этих самых "неких общих правил"?

из астрала?

или таки придется разработчику самому их разработать? тогда в чем профит для разработчика?

а может, они будут ниспосланы нам Создателем Мегаконфигурярки в виде скрижалей?

> Окинул беглым взглядом и создалось впечатление, что для конфигов она не очень-то предназначена.

Вопрос был -- как реализовать операцию записи для ФС, у которой storage -- LDAP. Была предъявлена работающая реализация. Специально для хранения конфигов она не предназначена.

>если не секрет, откуда их взять, этих самых "неких общих правил"?

из описания типов данных + схема приложения

>или таки придется разработчику самому их разработать?

схему? придется, да. Правда, для этого надо сильно больше мозгов, нежели пихать в код eval()

>тогда в чем профит для разработчика?

хотя бы в том, что он сможет повыкидывать массу проверок из кода вместе с парсером

Для xml так сложно написать схему? Для s-exp так сложно сделать проверку на то, что строка должны быть строкой а не, к примеру, числом? Разработчику, которому нужно просто записать/считать сторку/число никаких схем придумывать не придется.

>Для xml так сложно написать схему? Для s-exp так сложно сделать проверку на то, что строка должны быть строкой а не, к примеру, числом? Разработчику, которому нужно просто записать/считать сторку/число никаких схем придумывать не придется.

вот именно. А посему - вопрос:

нахрена огород городить?

2tailgunner

>Достигается и другими языками.

Пример пожайлуста. Только не абстрактный, а для этого языка должен быть 1 Парсер и 2 Генератор. Тоесть я хочу считать конфиг программами на Perl, Python, Ruby, PHP, C, C++, Pascal, OCaml. Потом внести в него изменения (пару параметров изменить). При этом я хочу чтобы в файле можно было писать комментарии и при изменении файла эти комментарии сохранились.

Итак????

2gaa >Ни в какую схему нельзя засовать что-то более сложное, чем проверку по regexp.

Проверку с помощью regexp, что число лежит в диапазоне от 100 до 455 в студию, иначе считаю, что вы сударь балобол.

>> Ни в какую схему нельзя засовать что-то более сложное, чем проверку по regexp.

> Проверку с помощью regexp, что число лежит в диапазоне от 100 до 455 в студию, иначе считаю, что вы сударь балобол.

^+{0,1}([1-3]\d\d)|(4([1-4]\d)|(45[1-5]))$ . Так что, сударь, извольте утереться.

+1 за yaml

и вообще, все предлагаемое здесь - полумеры.

Дайош кнопку "Сконфигурить фсио"!!11

> Дайош кнопку "Сконфигурить фсио"!!11

Нет, нужна кнопка "Сделать всё [censored] (в общем, очень хорошо)"!!!

2gaa

>^+{0,1}([1-3]\d\d)|(4([1-4]\d)|(45[1-5]))$ . Так что, сударь, 
извольте утереться.

силен мерзавец. А как-же фраза XML нечитаем? Бумеранг?

А теперь аналог в регулярных выражениях такого:

<!DOCTYPE CATALOG [
		
<!ENTITY AUTHOR "John Doe">
<!ENTITY COMPANY "JD Power Tools, Inc.">
<!ENTITY EMAIL "jd@jd-tools.com">

<!ELEMENT CATALOG (PRODUCT+)>

<!ELEMENT PRODUCT
(SPECIFICATIONS+,OPTIONS?,PRICE+,NOTES?)>
<!ATTLIST PRODUCT
NAME CDATA #IMPLIED
CATEGORY (HandTool|Table|Shop-Professional) "HandTool"
PARTNUM CDATA #IMPLIED
PLANT (Pittsburgh|Milwaukee|Chicago) "Chicago"
INVENTORY (InStock|Backordered|Discontinued) "InStock">

<!ELEMENT SPECIFICATIONS (#PCDATA)>
<!ATTLIST SPECIFICATIONS
WEIGHT CDATA #IMPLIED
POWER CDATA #IMPLIED>

<!ELEMENT OPTIONS (#PCDATA)>
<!ATTLIST OPTIONS
FINISH (Metal|Polished|Matte) "Matte" 
ADAPTER (Included|Optional|NotApplicable) "Included"
CASE (HardShell|Soft|NotApplicable) "HardShell">

<!ELEMENT PRICE (#PCDATA)>
<!ATTLIST PRICE
MSRP CDATA #IMPLIED
WHOLESALE CDATA #IMPLIED
STREET CDATA #IMPLIED
SHIPPING CDATA #IMPLIED>

<!ELEMENT NOTES (#PCDATA)>

]>

>> ^+{0,1}([1-3]\d\d)|(4([0-4]\d)|(45[0-5]))$ . Так что, сударь,
извольте утереться.

> силен мерзавец. А как-же фраза XML нечитаем? Бумеранг?

Я предлагал сохранять конфиги в регекспы? Откстись :) Я всего лишь сказал, что валидатор в gconf не сможет проверить нечто большее чем регексп на переданном ему значении и логику монопенисуально придётся вынести в программу.

> А теперь аналог в регулярных выражениях такого.

DTD-шками не владею, посему придмывать не буду.

> Дядя - ты не в теме. Тебе еще раз сказали - если есть DTD конфига - то легко и непренужденно по нему сгенерировать конфигурялку.

Выразишь на DTD условие "поле x1 должно быть меньше x2, а поле x3 должно быть нечетным"?

ну вот зачем опять валить всё в одну кучу? Одно дело - API для информирования приложений об изменившихся настройках, другое - для централизованного хранения, а третье - это представление этих самых настроек и т.п.

Почему это разные вещи? Потому что никому это ВСЁ СРАЗУ не нужно. Кому-то нужен простой способ сохранить дерево параметров, кому-то -- централизованно хранить, а другим товарищам нужно ACL для каждого чиха.

Запихнуть столь ортогональные вещи в один API - это породить очередного монстра.

Но вместе с тем это не отменяет поиска решений для поставленных задач - что ж делать? Думать, думать, думать. Конечная система должна их решать, но не думаю что это будет какое-то единое API, скорее грамотно спроектированный стек, по типу TCP/IP: есть транспортный уровень, есть канальный и т.п. И задача будет решаться с привлечением необходимых мощностей.

А из критики единого решения - ну нафига мне на моём КПК блокнот, который будет уметь настройки размера шрифта на LDAP-сервер посылать, да ещё в XML? ;-))

Ну а что касается того, что вы по схеме сгенерите ГУИ-конфиг - полный бред. Вы нагенерите кучу полей ввода, которая является не интерфейсом, а более извратным методом правки конфига. Ну получу я сообщение о том, что в поле для IP-адреса нельзя вводить буквы сразу же, а не после попытки рестарта демона. Семантику всё равно проверить нельзя. Хороший интерфейс тем и отличается, что кое-что знает о логике работы приложения помимо типов параметров.

> что касается того, что вы по схеме сгенерите ГУИ-конфиг - полный бред. Вы нагенерите кучу полей ввода, которая является не интерфейсом, а более извратным методом правки конфига.

+1

> Семантику всё равно проверить нельзя

В общем случае, для этого придется писать проверяющий код.

Короче говоря, большинство приходит к мнению, что делать ничего не надо. Вообще ничего. Т.е. мы будем и дальше все дружно сидеть одной жопой на 1000 велосипедах и радоваться.

Мое мнение, что можно хотя бы попытаться разработать новую, более совершенную модель для управдения системой. Да, будут неудачи. Да, будут набитые шишки. Но, в конце концов, появится система, которая проживет еще лет 40. И наши дети точно так же будут троллить, что нех ее трогать, что она самая надежная и очевидная, когда кто-то намекнет о том, что она устарела.

>Ну а что касается того, что вы по схеме сгенерите ГУИ-конфиг - полный бред. Вы нагенерите кучу полей ввода, которая является не интерфейсом, а более извратным методом правки конфига

гуевые морды к ldap генерят формы. Хоть какие-то. Маньяки могут править ldif в емаксе - кто ж им запретит.

но формы генерятся. А для приведения форм в чуйство используется несколько подходов...в основном полуавтоматические. Грубо говоря - раскидываешь атрибуты по группам, а группы по панелям. Всё.

>Семантику всё равно проверить нельзя.

почему? Патрик не велел?

> формы генерятся. А для приведения форм в чуйство используется несколько подходов...в основном полуавтоматические. Грубо говоря - раскидываешь атрибуты по группам, а группы по панелям. Всё.

А валидация где? Кроме примитивной. Скажем, чтобы имя хоста было не просто строкой, а резольвящимся именем хоста.

>А валидация где? Кроме примитивной.

так хотя бы примитивная. В отличие от никакой

>Скажем, чтобы имя хоста было не просто строкой, а резольвящимся именем хоста.

чушь и бред, резолвинг хостнейма - характеристика непостоянная

>> А валидация где? Кроме примитивной.

> так хотя бы примитивная. В отличие от никакой

Для примитивной не нужен XML.

>> Скажем, чтобы имя хоста было не просто строкой, а резольвящимся именем хоста.

> чушь и бред, резолвинг хостнейма - характеристика непостоянная

Это означает только то, что один и тот же конфиг в разное время может быть валидным или невалидным.

>Для примитивной не нужен XML.

если до тебя ещё не дошло - повторяю в сотый раз - XML - ОДНО ИЗ ВОЗМОЖНЫХ ХРАНИЛИЩ, МАТЬТВОЮ

если напишешь адекватное зумлю ini-style - показывай

>Это означает только то, что один и тот же конфиг в разное время может быть валидным или невалидным.

нет. Это означает всего лишь, что за доступность внешних сервисов конфиг отвечать не может.

> если до тебя ещё не дошло - повторяю в сотый раз - XML - ОДНО ИЗ ВОЗМОЖНЫХ ХРАНИЛИЩ, МАТЬТВОЮ

Медленно и печально повторяю: валидация конфига в общем случае невозможна без написания для этого специалного кода, Понятно, матьтвою?

> если напишешь адекватное зумлю ini-style - показывай

Этим деццким заболеванием я переболел лет 15 назад %)

>Медленно и печально повторяю: валидация конфига в общем случае невозможна без написания для этого специалного кода, Понятно, матьтвою?

возможна

>Этим деццким заболеванием я переболел лет 15 назад %)

походу это заболевание сказалось на мозге

>> Этим деццким заболеванием я переболел лет 15 назад %)

> походу это заболевание сказалось на мозге

Может быть :D Но, по крайней мере, мой мозг оно больше не жрет %)

>Но, по крайней мере, мой мозг оно больше не жрет %)

кончился? =)

>> Но, по крайней мере, мой мозг оно больше не жрет %)

> кончился? =)

Неважно... сейчас она жрет твой моск, лечись, ПОКА НЕ ПОЗДНО!!!111

Или уже поздно? o_O

>Неважно... сейчас она жрет твой моск, лечись, ПОКА НЕ ПОЗДНО!!!111

не жрет, представь себе.

>> Неважно... сейчас она жрет твой моск, лечись, ПОКА НЕ ПОЗДНО!!!111

> не жрет, представь себе.

Кончился? =)

>не жрет, представь себе.

кончился?

>> формы генерятся. А для приведения форм в чуйство используется несколько подходов...в основном полуавтоматические. Грубо говоря - раскидываешь атрибуты по группам, а группы по панелям. Всё.

> А валидация где? Кроме примитивной. Скажем, чтобы имя хоста было не просто строкой, а резольвящимся именем хоста.

Ну делаем три файла. Первый генерится из схемы и содержит в себе все имена и группы. Второй дизайнится в дизайнере и описывает форму. Третий пишется в редакторе и описывает логику. На любом языке с рефлексией это достаточно простая задача.

> Ну делаем три файла.

Ниасилил, зачем это всё. Или ты тоже хочешь сказать, что в общем случае для валидации придется писать программу?