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

> Каждому делу - свой инструмент. А ты пытаешься ножницами для стрижки ногтей разжигать костер.

Классически принято называть это забиванием гвоздей микроскопом :)

> Они будут рассказывать, что наличие валидатора в КАЖДОЙ!!! программе лучше одного DTD валидатора и это уменьшает программы и делает их безопаснее. Они утверждают, что sendmail.cf читабельнее XML. Они утверждают, что переносить кусочки текстовых файлов из одного в другой надежнее, чем перенос поддерева DOM.

Ну как бы ты и привёл все доводы нелюбителей XML. Причём даже ничего не переврал.

ну и по отдельным словам:

1) проверь мне DTD-валидатором доступность машины, указанной в поле host.

2) запросы к базе ты тоже на XML пишешь? или всё же используешь sql?

3) а тут говорили, что кончный формат -- это фигня и никакие куски дерева переносить не надо. кто прав?

>Как, в Божественном ГОбъекте этого ещё нет? :о)

вообще-то есть, но навесным способом, что не труъ

> Ошибка именно в этом. Надо было их выкинуть - быстрее бы отладили новый формат. А то пикейные жилеты текстовых форматов не помогали в тестировании...

"Разрушим всё до основанья... Мы наш, мы новых XML построим..." :)

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

>Взять парсеры пяти-шести распространённых форматов,

а остальные куда?

>ибо никто не даст fuse на этапе оченб ранней загрузки смонтировать в /etc.

этап "очень ранней загрузки" находится в initrd, а туда и иксы запихнуть можно, если захотеть

> Что плохого в едином API даже только для чтения конфигов?

Стандартный ответ: он настолько же неудобен, насколько всеобщ. Надеюсь tailgunner не обидится на то, что я ответил на вопрос, адресованный ему.

>> Взять парсеры пяти-шести распространённых форматов,

> а остальные куда?

Остальные считать форматом "script" и складывать в базу как есть.

> этап "очень ранней загрузки" находится в initrd, а туда и иксы запихнуть можно, если захотеть

Бугага, простите

>он настолько же неудобен, насколько всеобщ.

неудобен кому?

>Остальные считать форматом "script" и складывать в базу как есть.

а проверять на корректность пушкин будет?

> и уведомление через dbus как будет работать? вот отредактировал я в емаксе конфиг - и что? libastral?

inotify

>> Остальные считать форматом "script" и складывать в базу как есть.

> а проверять на корректность пушкин будет?

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

>inotify

дескрипторы не бесконечны, а при активном юзании inotify в системе на файловые вызовы будет накладываться нехилый оверхед.

> дескрипторы не бесконечны, а при активном юзании inotify в системе на файловые вызовы будет накладываться нехилый оверхед.

Это деталь реализации(c)

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

шило на мыло. Перечитай тред ещё раз, может асилишь идею.

если тебе нравится писать по парсеру и валидатору для каждой проги в случае если ты решил написать конфигурялку, ldap импортилку/экспортилку или ещё какое взаимодействие между софтинами, требующее когерентности конфигов, организовать - пожалуйста.

но называть это _правильным_ способом решения фундаментальной проблемы может только идиот.

>> он настолько же неудобен, насколько всеобщ.

> неудобен кому?

В пределе, каждому. Тут нужно уловить разницу между "всем" и "каждому".

>Это деталь реализации(c)

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

>В пределе, каждому.

в пределе - всем удобен.

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

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

> если тебе нравится писать по парсеру и валидатору для каждой проги в случае если ты решил написать конфигурялку, ldap импортилку/экспортилку или ещё какое взаимодействие между софтинами, требующее когерентности конфигов, организовать - пожалуйста.

Задача ничем не сложнее переписывания _всех_ программ под gconf.

> но называть это _правильным_ способом решения фундаментальной проблемы может только идиот.

Фундаментальная проблема -- в головах конфигофашистов.

>> В пределе, каждому.

> в пределе - всем удобен.

Потому что keeg так решил? Бугуга.

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

Профиты централизованного хранения конфигов есть, а профитов единого конфигового api нет.

>Потому что keeg так решил? Бугуга

я написал, почему. Попробуй включить моск

>Профиты централизованного хранения конфигов есть, а профитов единого конфигового api нет.

есть. Схемы, валидация, автоматическая генерация конфигурялок любого вида, комбинирование веток из _разных_ источников нужным способом, автоматическое отслеживание когерентности конфигов, которое, к слову сейчас достигается исключительно с помощью костылей типа virtualmin, а эти костыли вообще не предусматривают ручную правку

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

>Задача ничем не сложнее переписывания _всех_ программ под gconf.

переписать их надо _один_ раз. Всё. В отличие от

>Фундаментальная проблема -- в головах конфигофашистов.

проблему не видят только идиоты.

> Схемы, валидация, автоматическая генерация конфигурялок любого вида, комбинирование веток из _разных_ источников нужным способом,

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

> автоматическое отслеживание когерентности конфигов

Так хранят конфиги только мудаки (с)

> к слову, я это уже десятый раз повторяю. Сколько раз мне ещё повторить, чтобы дошло?

Повтори ещё раз 10, может дойдёт, что за глупость ты повторяешь.

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

возможно

>Так хранят конфиги только мудаки (с)

офигеть. Все хостинговые конторы и гугль - мудаки. Ты открыл мне глаза

>> Задача ничем не сложнее переписывания _всех_ программ под gconf.

> переписать их надо _один_ раз. Всё.

Даже не знаю, как выразить в словах разбирающий меня хохот.

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

если ниасилил, почему "один раз" - так и скажи. Я тебе даже объясню.

> если ниасилил, почему "один раз" - так и скажи. Я тебе даже объясню.

если ты ниасилил, что это никому не надо, то вперед, доказывай идею реализацией на собственном примере: шли патчики мейнтейнерам этих программ, организовывай когерентное окружение и единое с ним взаимодействие. Никто за тебя эту работу делать не будет, ибо нафиг она кому сдалась. А на ЛОРе троллить все горазды, а как доходит до приложения собственного труда и времени, то куда-то сразу пропадают. В мире FOSS люди выглядит убедительнее, если указывает на недостатки не с пустыми словами, но и подтверждает свою речь кодом.

Отсюда главный вопрос: что сделал geek для реализаций своей идеи, кроме как обсирал чужие альтернативные подходы?

> Пример от эксэмэлофоба

{xorg:
{monitor:
res(1024,768,32bit)
model(LG,FLATRON,F720B)

}
{mouse:
model(Genuius,NetScroll+,)
}
{modules:
load(xgl)
load(xv)
load(ttf)
}
include($USER/.x.conf)
}

{xorg:
       {monitor:
		res(1024,768,32bit)
		model(LG,FLATRON,F720B)
		
	}
	{mouse:
		model(Genuius,NetScroll+,)
	}
	{modules:
		load(xgl)
		load(xv)
		load(ttf)
	}
	include($USER/.x.conf)
}

# Это схема знаком ! - обозначаются
# обязательные элементы
# ... - возможность повторения элементов
{!xorg:
       {!monitor...:
		!res(!int,!int,!bits)
		!model(!text,text,text)
		
	}
	{!mouse...:
		!model(!text,text,text)
	}
	{!modules:
		load...(!text)
	}
}

>Это - выигрыш? Существуют хорошие парсеры JSON, ini и прочих.

1) Нужны не только парсеры - файл еще и записать надо - тоесть нужен генератор. Причем генератор JSON который Считает JSON с комментариями (такой вообще существует?) Потом я внесу изменения из программы потом запишу И ВСЕ Комментарии останутся

2) INI не подходит. Ну вот не поджходит и все. Загляни в конфиг Gajimа - он портится регулярно потому, что там INI извратили для работы с деревом. И портится этот файл без ручного редактирования

3) Количество биндингов XML парсеров к другим языкам явно привосходит количество JSON биндингов, да и других тоже

4) JSON или кто другой - тот-же Yaml имеют механизм аналогичный DTD?

Насчет императивной проверки. Да есть такое, но лучше 99% верификации чем 1% в случае с INI

>Это - выигрыш? Существуют хорошие парсеры JSON, ini и прочих.

1) Нужны не только парсеры - файл еще и записать надо - тоесть нужен генератор. Причем генератор JSON который Считает JSON с комментариями (такой вообще существует?) Потом я внесу изменения из программы потом запишу И ВСЕ Комментарии останутся

2) INI не подходит. Ну вот не поджходит и все. Загляни в конфиг Gajimа - он портится регулярно потому, что там INI извратили для работы с деревом. И портится этот файл без ручного редактирования

3) Количество биндингов XML парсеров к другим языкам явно привосходит количество JSON биндингов, да и других тоже

4) JSON или кто другой - тот-же Yaml имеют механизм аналогичный DTD?

Насчет императивной проверки. Да есть такое, но лучше 99% верификации чем 1% в случае с INI

# Или - так
# Это схема знаком ! - обозначаются
# обязательные элементы
# * - возможность повторения элементов
{!xorg:
       {!monitor*:
		!res(!int,!int,!bits)
		!model(!text,text,text)
		
	}
	{!mouse*:
		!model(!text,text,text)
	}
	{!modules:
		load*(!text)
	}
}

И что? ФС говно, так никто не предлагает заменять ext3/xfs/etc на маковую фс. А вот система конфигов там сделана удобно, и их вполне можно взять.

>ибо нафиг она кому сдалась

а вот это 4.2. вот мне, например, это нужно

> 1) проверь мне DTD-валидатором доступность машины, указанной в поле host.

А зачем? DTD должен проверять, что этот хост имеет валидное имя, и вместо example.com не попадет какое-нить !^&%&%3134dfgd@#

# А это пример описания параметров схемы
# для User Friendly GUI
# Интернационализация посредством gettext например

{!xorg:
{!monitor*:
!res( !int _(X Resolution) ,
!int _(Y Resolution) ,
!bits _(Color depth)
) _(Resolution and bits)

!model(!text,text,text) _(Model)

}
{!mouse*:
!model(!text,text,text) _(Model)
}
{!modules:
load*(!text _(xorg module name)) _(XOrg module loading)
}
}

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

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

> Но когда желание тянуть всё подряд из макоси становится просто привычкой -- вот это плохо.

Зачем все подряд? Но идея с централизованной системой конфигурации - это очень правильная идея. И линуху тоже придется к этому прийти - чем раньше, тем лучше.

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

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

> Программист для этого выберет конфиг, отражающий решаемую задачу, а не конфиг, отражающий чьё-то желание (не будем показывать пальцем) построить всё под один хмл

Феерический бред. XML - это только форма. А "отражающий реальную задачу" - это характеристика конфига с т.зр. содержания.

> semdmail.cf -- это кошмарнейший из кошмаров в /etc?

А что - разве это поменялось?

> Это деталь реализации(c)

Согласен. Но чтобы изменить эту деталь, надо переходить на совершенно другие ОС. Мы говорим о Линухе или где?

> Я тогда назло svu сделал сохранение локализованных комментариев в текстовый файл настроек

Назло мне сделаете конфигурирование tklor из ldap? А из СУБД?

> Программист для этого выберет конфиг, отражающий решаемую задачу, а не конфиг, отражающий чьё-то желание

Таки да.

> Феерический бред.

Вы неправы.

> XML - это только форма.

А зачем она нужна -- эта самая форма без содержания? Что она такого позволяет, чего без неё нельзя сделать? Вариант "записать простое лямбда-выражение в 10 листов формата A5" не рассматривается.

>если ты ниасилил, что это никому не надо

с чего ты взял, что это никому не надо?

> А зачем она нужна -- эта самая форма без содержания?

Форма нужна для единства API. Единого парсера. Единого подхода к метаданным и локализации. И почему "без содержания"? Содержание надо вкладывать в любом случае - будь то xml или кто еще.

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

Как админ > 50 локалхостов, скажу Вам: сверните это Ваше "единое API" в трубочку, и засуньте поглубже. Удобнее текстовых файлов и скриптов пока ничего не придумали (и вряд ли придумают).

> нужен. И не на уровне конфига, а на уровне ключа

ну так подели конфиги соответствующим образом, чай не вында.

> Ну или базовые настройки приложений могут лишь частично меняться пользователями.

Типичный вындовз-вэй. Базовые настройки должны меняться только рутом. Всё что меняется данным юзером - раскинуто по хомякам. Короче, man юниксвей ::))

>я так плохо задаю вопросы? Повторяю - отредактировал я емаксом файл с конфигом шрифтов. Что дальше? Мне надо руками запускать dbus-send?

Ты не внимательно читаешь. На этот вопрос я уже ответил.

> чего не ребут сразу?

Ну так разуй глаза, посмотри свой etc. Там скриптов немеряно. Как ты их собираешься отслеживать? Или gconf у нас уже скрипты парсит?

>нет прав доступа, нет возможности собирать конфиг из нескольких бакендов, нет метаданных...да ничего нет. Так что QSettings может покрыть потребности только убогих разумом.

Ну так зайди на qt-apps посмотри на убогих разумом. Но боюсь, ты уже окажешься в меньшинстве ::))

> Форма нужна для единства API.

А зачем оно нужно? Чтоб всем было одинаково хреново?

> Единого парсера.

Тот же вопрос. Вы что, хотите, к примеру, чтоб postfix смог распрасить конфиг apache? А зачем?

> И почему "без содержания"?

А где оно?

> А зачем оно нужно?

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

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

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

> А где оно?

Унутре xml

>> 1) проверь мне DTD-валидатором доступность машины, указанной в поле host.

> А зачем? DTD должен проверять, что этот хост имеет валидное имя, и вместо example.com не попадет какое-нить !^&%&%3134dfgd@#

А затем, что это -- часть проверки валидности. Или есть хорошая валидность, которая в DTD укладывается, и есть нехорошая, которая нет? :)

Кстати, еще вопрос: какое dtd мне проверит, что слово, указанное в конфиге является палиндромом? :)

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