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

В базе данных будут комментарии и диапазоны для строк конечно же.

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

Ну так это.. Вперёд. Если идея действительно хороша, то она не останится без внимания.

А почему в некоторых дистрах кастрируют пакеты

выкидыва то что не осилили собрать

и конфиги ты предлагаешь конечно же править ручками в текстовом редакторе?

да.

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

ну нарисуй мне гуй для настройки моего emacs

в XML или БД сможет хранить сложные конфиги. На которые потом можно будет натравить ORM типа Hibernate'а

пройдите в топку локалхоста, будьте уж так любезны.

Вот реальная задача.

Есть такая вполне обычная прога, DNS-сервер BIND. Формат конфига ты, наверное, знаешь (эдакая уродская си-подобная фиготень). Теперь представим что мы пишем прогу, которая управляет конфигом BIND. Причем прога может работать сразу с несколькими пользователями (через RPC или вебморду). Есть «расширенный» вариант конфига, синхронизированный с «основным». Основное отличие - в расширенном варианте для каждого изменения конфига есть маркер кто его создал. Во время чекпоинтов (по времени или по критическим действиям) «расширенный» конфиг синхронизируется с «основным»: теряются типы действий, права пользователей, история, и остается только конфиг зон, после чего Bind перезапускается с новыми параметрами.

так вот пока я это писал, я задолбался, риально. Если бы там была БД, всё это писалось бы за часы. А так только сочинение формальной грамматики конфига для AntLR заняло фиг знает сколько времени.

> в расширенном варианте для каждого изменения конфига есть маркер кто его создал. Во время чекпоинтов (по времени или по критическим действиям) «расширенный» конфиг синхронизируется с «основным»: теряются типы действий, права пользователей, история, и остается только конфиг зон, после чего Bind перезапускается с новыми параметрами.

Бинд же тупо позволяет заинклудить нужные конфиг файлы одной строчкой, не?

>Есть такая вполне обычная прога, DNS-сервер BIND. Формат конфига ты, наверное, знаешь (эдакая уродская си-подобная фиготень). Теперь представим что мы пишем прогу, которая управляет конфигом BIND. Причем прога может работать сразу с несколькими пользователями (через RPC или вебморду). Есть «расширенный» вариант конфига, синхронизированный с «основным». Основное отличие - в расширенном варианте для каждого изменения конфига есть маркер кто его создал. Во время чекпоинтов (по времени или по критическим действиям) «расширенный» конфиг синхронизируется с «основным»: теряются типы действий, права пользователей, история, и остается только конфиг зон, после чего Bind перезапускается с новыми параметрами.

Короткий список того, что нужно было сделать
- Берем любую VCS
- Пишем простой bash скрипт для того, чтобы после редактирования любимым редактором файл коммитился
- PROFIT

Берем любую VCS

В общем случае это не работает. Но с определёнными ограничениями вполне пойдёт.

> Бинд же тупо позволяет заинклудить нужные конфиг файлы одной строчкой, не?

нужно понимание и полный разбор конфига, и наоборот - компиляция внутреннего представления в конфиг бинда. Т.е. прога должна понимать конфиг бинда «в обе стороны», кто бы его не создал и редактировать на уровне смысла.

скормить свой конфиг (который потом сам же и не сможешь распарсить назад) - это жалкий недовариант

Нужен полный разбор - напиши однострочник, делающий замены файлов. Там синтаксис примитивный до безобразия.

> - Пишем простой bash скрипт для того, чтобы после редактирования любимым редактором файл коммитился

это не работает как раз из-за высказанных предположений:
1) пользователи изменяют конфиг _одновременно_ (хотя одновременность потом и вылинеивается, ибо файл). И даже не один, а два, причем в «расширенном» конфиге есть связанные поля. И транзакции тут именно при этом.
2) пользователи добавляют, убирают и редактируют _сайты_. Про всякие сервера и прочее они понятия не имеют, а потому конфиг бинда им не скажет вообще ничего.
3) Дать им редактировать конифг бинда в текстовом редакторе - невозможно, потому что они могут туда нагадить. Любые входные данные должны проходить строгую проверку на тупняк, ересь и злопыхательство.

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

а ты понимаешь что предлагаешь костыли (по сравнению с нормальным разбором)?

а будь там БД, разбирать собственно нечего бы было.

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

> а ты понимаешь что предлагаешь костыли (по сравнению с нормальным разбором)?

Текстовая замена - не костыль.

а будь там БД, разбирать собственно нечего бы было.

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

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

не пришлось слишком много переделывать.

учитывая что там «помойная табилца», как выразился Мелькор, переделывать почти ничего и не надо.

а вот в текстовом конфиге тебе придется допиливать компилятор и декомпилятор конфига. А если компилятор сложный (не ключ=значение без проверки типов, а хотя бы как у бинда)...

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

Всё равно костыльно. Приложение должно быть файловым сервером, как в Plan 9.

$ cat /app/cfg
name cooker
limit 500
color green
$ echo 'limit 0' >/app/cfg
$ cat /app/cfg
name cooker
limit 0
color green

>а вот в текстовом конфиге тебе придется допиливать компилятор и декомпилятор конфига. А если компилятор сложный (не ключ=значение без проверки типов, а хотя бы как у бинда)...
Вот смотрите, мы можем добавить в бинде в options параметр
upyachka{
cat «good»;
dog «not» version 3 color red;
};
И оно совершенно не потребует изменений в парсере.

И как сделать возможность такого-же гибкого изменения, когда конфиг хранится в БД, чтобы БД не скатилось в УГ?

> И оно совершенно не потребует изменений в парсере.

это смотря чо у тебя за парсер.

во-первых, нужно проверить, является ли «упячка» валидным ключевым словом верхнего уровня. Потом проверить, являются ли cat и dog валидными спецификаторами для упячки. Потом, является ли валидной последовательность «cat $string» и «dog $string version $int color $color». Нужно обязательно проверить, является ли «good» валидной строкой. Потом когда перешли на более осмысленный уровень, проверить имеет ли смысл для собаки параметр «версия» одновременно с параметром «цвет», и могут ли одновременно внутри одной упячки встречаться cat и dog с такими параметрами.

и если внезапно что-то из этого не так, выдать осмысленную ошибку: на какой строчке не так и что поправить. Если ошибка мелкая (пропущена точка с запятой там, где она без вариантов быть должна) - выдать ворнинг, подставить автоматически, и продолжать парсинг.

как хорошо что ты не написал про приведение типов)

>А что мешает написать консольную конфигурялку? На curses или или чисто cli, `man gconftool-2`.
Здравый смысл, помешавший тащить dbus+glib на сервер.

>GConf рулит и педалит!
Настолько, что к третьему гному пилят велосипед для его замены.

>во-первых, нужно проверить, является ли «упячка» валидным ключевым словом верхнего уровня. Потом проверить, являются ли cat и dog валидными спецификаторами для упячки. Потом, является ли валидной последовательность «cat $string» и «dog $string version $int color $color». Нужно обязательно проверить, является ли «good» валидной строкой. Потом когда перешли на более осмысленный уровень, проверить имеет ли смысл для собаки параметр «версия» одновременно с параметром «цвет», и могут ли одновременно внутри одной упячки встречаться cat и dog с такими параметрами.
Это все в любом случае проверяется при загрузке параметров. И я уже много раз спрашивал, и еще раз спрашиваю, вы как собираетесь это хранить в таблице то?

долго описывать.
Если коротко, после парсинга текстового конфига у тебя что получается? Правильно, дерево. Вот как есть - так и сохраняем его в БД. По таблице на каждый уровень иерархии кейвордов (или списков параметров, или чего там твой язык должен позволять). Я даже не знаю как это объяснить в одном посте. Прочитай какую-нибудь методичку про абстрактные синтаксические деревья, что ли...

http://pastebin.com/QTig3Ev0
Вот конкретный маленький пример простого конфига из 23 строк. Приведите хотя-бы примерную оптимальную структуру БД.

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

>В бздях и солярах хуже помойка.

Ну да. Вы BSD вообще видели?

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

>Ну да. Вы BSD вообще видели?

К сожалению.

Me принял профилактическую дозу валерианы, освежил в памяти содержимое словарной статьи «Сетевой тролль» и читает сию нить с холоднокровием Великого Змея.

Про whereis и иже с ним ещё не говорили?

Юзай FreeBSD. Там все пользовательские программы используют /usr/local/etc/ для хранения своих Ъ-конфигов. X'ы — исключение.

Там все пользовательские программы используют /usr/local/etc/

В MS SQL?