Ну вот и дождались Linux Registry!!! Ура!!!

> 1) идет в противоположную сторону от *NIX way (разбиение общей задачи на мелкие функционально-незваисимые подзадачи)

Почему? библиотечка стандартизирует все, через нее все и работает. Никто не пишет свой парсер все используют ее. как например все используют cat, ls, и т.д. Еще есть rg для управления из скриптов, сделать rgcat думаю не трудно. И все, еще одна вещь стандартизированна и можно использовать, как например grep.

> 2) Поддержание _непротиворечивости_ такого "реестра" может стоить весьма дорого - одна ошибка в одном из многих конфигов имеет меньшие шансы "обрушитиь" систему нежели в предлагаемом монстре

Там же куча файлов, а не один. Если один неправильный то остальные не пострадают.

> 3) *NIX-оид по своей природе консервативен (точнее ленив) не зря же в *NIX рулит API из аж ЧЕТЫРЕХ функций ;)

Там примерно столько и будет :) Может чуть больше.

Да!??!?

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

> а. Причем именно про этот ключик - а не про ветку x.y.

И тут начались транзакци....так????

Охренеть....

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

вставлю свои 50 cent: когда я писал на фоксе report engine, оказалось, что многие вещи, параметры отчета, можно хранить в полях базы. даже оказалось, что некую унификацию можно получить, однотипные отчеты свести к одному, но с параметрами. но вот этих групп отчетов - много, и для них нужен разный код. т.е. самый центровой кусок формирования отчета, удобнее описывать куском кода хранимого в той же базе. а на формализацию - потратить пару лет, написать аххуеннейший движок который будет генерить любой отчет, и придумать систему этих параметров - все равно не получится. да и некрасиво.

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

> Ась ?

На седьмой странице, int19h сказал что он протестировал LR и описал как там все на самом деле, там нет XML. rg просто экспортирует в XML если надо.

>Там же куча файлов, а не один. Если один неправильный то остальные не пострадают.

Я смотрел не на файлы а на предлагаемый код ... один неверный cuta&paste и там ТАКОЕ может быть ... ;)

>Почему? библиотечка стандартизирует все, через нее все и работает.

Именно. Лишняя сущьность в виде лишней _универсальной_ библиотеки.

>1) идет в противоположную сторону от *NIX way (разбиение общей задачи на мелкие функционально-незваисимые подзадачи)

Как раз наоборот. Она разбивает задачу чтения конфига на независимые задачи чтения частей конфига:-).

>2) Поддержание _непротиворечивости_ такого "реестра" может стоить весьма дорого

Чуть сложнее, чем в одном текстовом файле - ибо там проще посмотреть несколько параметров сразу. Но не сильно - 'cat реестр/sub/dir/*/* | more' - и проверяй себе.

> На седьмой странице, int19h сказал что он протестировал LR и описал как там все на самом деле, там нет XML. rg просто экспортирует в XML если надо.

а до конца прочитать, что написал sS сложно? он экспортирует в xml, который вы редактируете, а потом импортируете - нормально, да?

> Отсутствие атомарных ChangeSets и нотификации об изменениях - это серьезные траблы.

> По поводу нотификаций. Если прога A поменяла ключик x.y.z - хочу, чтобы прога B была оповещена. Причем именно про этот ключик - а не про ветку x.y.

может послать feature request, пока не поздно ? С другой стороны можно время изменения проверять ...

> И тут начались транзакци....так????

"Вы поняли меня с полуслова!":) (с) "Покровские ворота"

Это я, на самом деле, с колокольни gconf смотрю. Все-таки там это удобно сделано...

> он экспортирует в xml, который вы редактируете, а потом
импортируете - нормально, да?

Эта фича только для слакварьщиков!

либо сами пишите rg офигеннодлинныйнепонятный ключ до путя. очень удобно.

зачем это надо? зачем нужна лишняя прослойка? это НЕ стандарт - это прослойка! вот один стандарт на конфиг файлы - было б здорово.

Елы палы, я скоро ругаться начну. Ну почему половину треда я должен распинаться о своей любви к скриптам?! Скрипты (юзер-модули) нужны, важны, полезны, необходимы и пр. и пр.

Пиз..ц! Осталось ещё только Кернел Паник на синем экране выводить...

> может послать feature request, пока не поздно ? С другой стороны можно время изменения проверять ...

Угу. Можно. Если делать на файловой системе - точно можно. Только, боюсь, FAM запарится такую развесистую файлопомойку обслуживать...

> Эта фича только для слакварьщиков!

еще раз:

The rg edit command provides an easy way to edit a group of keys using your prefered editor. It will dump the selected keys into an XML representation, and run the editor to let the user edit them. After user modifications, it will update, remove or include the keys based on the modified XML file.

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

кстати, раз вы уж сами начали: Слака рулит неподецки :)

вставлю свои 50 cent: когда я писал на фоксе report engine, оказалось, что многие вещи, параметры отчета, можно хранить в полях базы. даже оказалось, что некую унификацию можно получить, однотипные отчеты свести к одному, но с параметрами. но вот этих групп отчетов - много, и для них нужен разный код. т.е. самый центровой кусок формирования отчета, удобнее описывать куском кода хранимого в той же базе. а на формализацию - потратить пару лет, написать аххуеннейший движок который будет генерить любой отчет, и придумать систему этих параметров - все равно не получится. да и некрасиво.

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

СКРИПТЫ, МОДУЛИ - РУЛЕЗ! respect svu.

На самом деле, конечно, можно счесть ChangeSets & notifications - оверкиллом, для огромного количества случаев ненужным. При подходе от LR их можно реализовать в виде внешних примочек. При подходе от PitStop - нельзя (можно, но зело геморройно).

> Как я понял, .aconf - это конфиг програмы конфигурирования.

Нет же! Это один из конфигов программы svu-API. Этакая надстройка к каждому .conf'у

> Но эта программа должна знать синтаксис файла конфигурации, который она будет править.

Синтаксис будет знать только эта прога - svu-API.

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

А разве их так много? И они в корне отличаются друг от друга? И не надо валить в эту кучу sendmail.cf - хорошим это не кончится и вовсе не по причине сложности этого файла. Сложность в понимании работы самого почтовика. Речь вроде как о гуяторе всякого общепотребного хлама, всяких fstab, XF86Config и проочих.

> Я смотрел не на файлы а на предлагаемый код ... один неверный cuta&paste и там ТАКОЕ может быть ... ;)

какое ? :) просто чего-то не понимаю :)

> Именно. Лишняя сущьность в виде лишней _универсальной_ библиотеки.

... решающей следующие проблемы: http://registry.sourceforge.net/#needs

> а до конца прочитать, что написал sS сложно? он экспортирует в xml, который вы редактируете, а потом импортируете - нормально, да?

ну вообще то не так. можно просто vi /etc/registry/sw/xfree/modules/load и все.

> По поводу нотификаций. Если прога A поменяла ключик x.y.z - хочу, чтобы прога B была оповещена.

Это вы о чём? Кому интересны изменения в smb.conf кроме самих smbd и nmbd? Если о том что изменив гуятором параметр в squid.conf необходимо выполнить squid -k reconfigure, дык кто мешает вставить в svu-API команду apply changes? Команда описывается в соответствующем .aconf

> ... решающей следующие проблемы: http://registry.sourceforge.net/#needs

учение Ленина истинно, потому что оно верно.

> дык кто мешает вставить в svu-API команду apply changes?

как это кто? гномий hig :))))

> Кому интересны изменения в smb.conf кроме самих smbd и nmbd?

Точно! Если допустить, что однажды samba перейдет на этот самый svu-API - почему бы не дать ей возможность отслеживать изменения в конфигурации?

> squid -k reconfigure

Угу. Поменял один параметер (какой-нибудь уровень отладочных сообщений) - и сразу весь сервис рестартовать. Мне кажется, это не очень красиво. А вот если бы squid мог бы через api зарегистрировать callback(s), привязанный к конкретным ключам...

>> дык кто мешает вставить в svu-API команду apply changes?
>как это кто? гномий hig :))))

Остроумно! :)

Очень, очень надеюсь.

P.S. У тебя, chucha, прикольный рисунок;)

> Если допустить, что однажды samba перейдет на этот самый svu-API

Ей не надо никуда переходить, это svu перейдёт на этот API! Я ж говорил, изменений в работе существующего софта не будет, остаются и старые .conf файлы. Появляется толька небольшая надстройка.

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

А она их и так отслеживает. Если мне не изменяет память, то работающий демон перечитыает smb.conf раз в минуту. Впрочем, это можно сделать и принудительно.

> Угу. Поменял один параметер (какой-нибудь уровень отладочных сообщений) - и сразу весь сервис рестартовать.

Зачем рестартовать? Команда squid -k reconfigure этого не делает. Как раз она перечитывает свой конфиг, да и на то есть определённые оговорки.

> Мне кажется, это не очень красиво.

Это просто здорово и не заметно на глаз.

> А вот если бы squid мог бы через api зарегистрировать callback(s), привязанный к конкретным ключам...

На кой этот паровоз? Инернет что-ли ускорится от этого? Или перечитывание конфига даёт офигенную нагрузку на сервер? Ни разу не заметил.

>какое ? :) просто чего-то не понимаю :)

Чего там непонятного ?

_Одно_ неверное движение и ты правишь не конфиг иксов а конфиг апача ;)

Один registryOpen(); на все конфиги - до этого мог додуматься только человек , родившийся с клеймом Designed for Micro$oft Windows ;))

>... решающей следующие проблемы: http://registry.sourceforge.net/#needs

то что формат passwd не похож на конфиг апача это проблема ? ;)))

а про различное местоположение и структуру конфигов в различных дистрибутивах дык это вообще клиника - они и через этот реестр будут различными иначе бы их столько просто небыло бы ;)

> ... решающей следующие проблемы: http://registry.sourceforge.net/#needs

"Complex solutions for simple nonproblems"

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

>А разве их так много? И они в корне отличаются друг от друга

Много. Попробуйте назвать навскидку 5 программ, пользующиеся _одинаковым_ синтаксисом конфига(init.d сценарии не в счет). Наверняка обнаружится, есть отличия в мелких деталях. Эти различия неоправданы. И всем было бы хорошо, если бы их не было. Учесть все можно. Но слишком трудоемко и результат очень раздут. А раздутую программу прудно поддерживать. Так что от унификации метода хранения конфигов можно только выиграть, если не слишком извращаться.

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

Разработчики чего хотят "единый API" ? Графических конфигурялок ?

>то что формат passwd не похож на конфиг апача это проблема ?

Чем это он не похож? Есть сущности(пользователи у одного,каталоги, модули,пр. у другого), у которых есть параметры со значениями. Отличие только одно - уровень "вложености" параметров. Но почему оно должно быть существенным?

> _Одно_ неверное движение и ты правишь не конфиг иксов а конфиг апача ;)

Ужас берет сколькими способами я могу снести свою систему когда есть рут, тем более если я программирую :) Одним больше одним меньше. При программировании никто не просит запускать прогу от рута. Можно сделать симлинк или изменять на время тестирования в другом месте где есть права на запись пользователю-программисту а не только руту. Это можно сделать симлинком.

> то что формат passwd не похож на конфиг апача это проблема ? ;)))

будем проблему локализовывать до тех пор пока она не исчезнет? А всю в целом проигнорируем?

> а про различное местоположение и структуру конфигов в различных дистрибутивах дык это вообще клиника - они и через этот реестр будут различными иначе бы их столько просто небыло бы ;)

Что то у меня вызывает сомнения этот вариант. Все же стандарт и различие взаимоисключают друг друга :)

> > _Одно_ неверное движение и ты правишь не конфиг иксов а конфиг апача ;)

> Ужас берет сколькими способами я могу снести свою систему когда есть рут, тем более если я программирую :) Одним больше одним меньше. При программировании никто не просит запускать прогу от рута. Можно сделать симлинк или изменять на время тестирования в другом месте где есть права на запись пользователю-программисту а не только руту. Это можно сделать симлинком.

Тем более это простые файлы, и можно расставить права, использовать ACL. Совсем необязательно пользователю user иметь права на запись в ветку апача, тем более самому апачу не обязательно иметь права на запись в свою же ветку.

Я б реестр в OO.org сделал - там хоть антиалиасинг нормальный и
важные места можно цветом и шрифтами выделять, а еще можно картинки и выпадающие списки в конфиги вставлять. Конфиг без картинок сасёт! :-)

Мля, 4 тысячелетие на носу, а вам бы все бы буквы читать, мля :-)

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

Госпидя! А кто вам мешает в начале каждого .aconf расписать синтаксис? Все перфиксы и суффиксы применяемые непосредственно в .conf? И не надо ничего раздувать! Более того не составляет труда даже самой мухосранской программе иметь свой .aconf и конфигурироваться через общий API!
Нет никакой сложности указать для dhcpd.conf параметр в dhcpd.aconf под именем типа end_conf_line = ';'
Не надо усложнять парсер!

2svu & поборникам стандартизации.
давайте еще переменные стандартизуем, разработчику - лафа полная. Б$%, давайте bashrc или profile в хымэль запихнем, любая программа будет при запуске вызывать парсер или сервис для разборки всей этой хымэль подливы. А чо, компы быстрые, оне успеют. В шопу это всё.
P.S. Недобор ближе к умеренности, чем перебор.
P.P.S. Любимая фраза программистов "сервер быстрый, он успеет".

2svu & поборникам стандартизации.
давайте еще переменные стандартизуем, разработчику - лафа полная. Б$%, давайте bashrc или profile в хымэль запихнем, любая программа будет при запуске вызывать парсер или сервис для разборки всей этой хымэль подливы. А чо, компы быстрые, оне успеют. И вызовы функций ядра чтоб параметры в хымэле понимали. В шопу это всё.
P.S. Недобор ближе к умеренности, чем перебор.
P.P.S. Любимая фраза программистов "сервер быстрый, он успеет".
P.P.P.S. Стандарт есть и уже давно, POSIX называется, не надо плодить сущности.

> Ей не надо никуда переходить, это svu перейдёт на этот API! Я ж говорил, изменений в работе существующего софта не будет,

Это сначала не будет. Мне что-то подсказывает, что при широком распространении и удобстве API его таки начнут широко пользовать (не только авторы linuxconf/webmin) - вместе с callbacks. Только до этого должны пройти года...

> работающий демон перечитыает smb.conf раз в минуту

Замечательно! Очень эффективный способ отслеживать изменения! Рулит, как говорится, и выруливает!

> Команда squid -k reconfigure этого не делает

Она умеет выполнять частичную реинициализацию подсистем в зависимости от списка измененных ключей? Если да - снимаю шляпу.

> Или перечитывание конфига даёт офигенную нагрузку на сервер? Ни разу не заметил.

Извините, прямо сейчас не смогу предоставить бенчмарк. Но очевидно, что немножечко производительности по сравнению с полной переинициализацией может быть сохранено. И - главное - концептуально, никакой лишней работы, никакого poll (опрос файловой системы) - только push (тех изменений, которые реально произошли).

> 2svu & поборникам стандартизации. > давайте еще переменные стандартизуем, разработчику - лафа полная. Б$%, давайте bashrc или profile в хымэль запихнем, любая программа будет при запуске вызывать парсер или сервис для разборки всей этой хымэль подливы. А чо, компы ыстрые, оне успеют. В шопу это всё. > P.S. Недобор ближе к умеренности, чем перебор. > P.P.S. Любимая фраза программистов "сервер быстрый, он успеет".

Там нет XML :)

> Там нет XML :)

http://registry.sourceforge.net/images/rgedit.png

>Чем это он не похож?

passwd - запись - строка с полями и ":" в качестве разделителя

httpd - в чистом виде key = value поделенное на секции

Это ладно: у меня вот была задачка в текстовом виде грузить

value = f(key1,key2,key3) - любые стандартные решения идут лесом (по разным причинам) ;)

> Там нет XML :)

Yesss!!! Сначала не понял, потом минуту ржал...:)

Это экспорт в XML и можно импорт обратно. и все. реестр не содержит в себе XML.

> Yesss!!! Сначала не понял, потом минуту ржал...:)

:)

Отлично! .aconf файлы есть текст на literate haskell, имеющий неявный "import Parsec", описывающий правила генерации из текста абстрактного дерева(и наоборот), которой и правится программой редактирования.

Боюсь, что это будет _самый_ _простой_ способ реализовать данную идею:-).