Scott TigerНе нужен. Мысль такая - каждой программе нужен свой формат конфигов, отражающий внутреннюю логику программы. Где-то достаточно пары "ключ-значение", где-то требуется иерархическая структура, где-то ещё что-то (списки и т.п.). Простота *nix во многом и связана с тем, что конфигурационные файлы подавляющего числа программ имеют простую структуру "ключ-значение", с одной стороны, легко воспринимаемую человеком и, с другой стороны, относительно легко поддающуюся автоматизации подручными средствами.
Отсутствие единого API работы с конфигами исключает возможность его неправильного использования низкоквалифицированными разработчиками, т.е., максимум куда такой кадр может нагадить бредовым кодом - это к себе в конфиг.
Я никогда не поддерживал тезис "кустарно - значит безопасно". Для безопасности настроек нужно использовать ACL, и прочие политики.
ПО, требующее сложноструктурированных конфигурационных файлов, как правило, само в такой степени сложно, что часть хранения конфигурационной информации будет едва ли не самой простой его частью.
Я думаю, такое ПО следует исключить из обсуждения. И так понятно, что сервер DNS крупной сети потребует более толстого и надежного хранилища нежели реестр.
Scott Tiger
Желание использовать какое-то единое решение, как правило, вырождается в конфиг на XML-е, который и парсится долго и ресурсоёмко (хотя это актуально только для часто вызываемых программ), и человеку для редактирования неудобен, и работа с этим гамном автоматизируется куда как сложнее. Хороший пример XML ни к месту - SMF в Solaris 10: сама структура не так сложна, чтобы было сложно сделать это на конфигах типа "ключ-значение", при этом инструментальные CLI-средства достаточно слабы и не выверены (нет чёткой идеологии или я её не ухватываю), нет GUI (есть черезжопие SMC, но о нём говорить не хочу), но нет и curses-интерфейса для управления.
Здесь согласен. XML не может претендовать на оперативность операций обновления.
Добавлю.
Я видел довольно причудливые попытки создать структурированное хранилище ключей в обычном плоском файле параметров.
Реальный пример конфига из Java:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
#
serif.latin1.plain=Times-Roman
serif.latin1.italic=Times-Italic
serif.latin1.bolditalic=Times-BoldItalic
serif.latin1.bold=Times-Bold
#
sansserif.latin1.plain=Helvetica
sansserif.latin1.italic=Helvetica-Oblique
sansserif.latin1.bolditalic=Helvetica-BoldOblique
sansserif.latin1.bold=Helvetica-Bold
#
monospaced.latin1.plain=Courier
monospaced.latin1.italic=Courier-Oblique
monospaced.latin1.bolditalic=Courier-BoldOblique
monospaced.latin1.bold=Courier-Bold
#
serif.x11jis0208.plain=Ryumin-Light-H
serif.x11jis0208.italic=Ryumin-Light-H
serif.x11jis0208.bolditalic=Ryumin-Light-H
serif.x11jis0208.bold=Ryumin-Light-H
#
sansserif.x11jis0208.plain=GothicBBB-Medium-H
sansserif.x11jis0208.italic=GothicBBB-Medium-H
sansserif.x11jis0208.bolditalic=GothicBBB-Medium-H
sansserif.x11jis0208.bold=GothicBBB-Medium-H
#
monospaced.x11jis0208.plain=GothicBBB-Medium-H
monospaced.x11jis0208.italic=GothicBBB-Medium-H
monospaced.x11jis0208.bolditalic=GothicBBB-Medium-H
monospaced.x11jis0208.bold=GothicBBB-Medium-H
#
serif.x11jis0201.plain=Ryumin-Light.Hankaku
serif.x11jis0201.italic=Ryumin-Light.Hankaku
serif.x11jis0201.bolditalic=Ryumin-Light.Hankaku
serif.x11jis0201.bold=Ryumin-Light.Hankaku
#
sansserif.x11jis0201.plain=GothicBBB-Medium.Hankaku
sansserif.x11jis0201.italic=GothicBBB-Medium.Hankaku
sansserif.x11jis0201.bolditalic=GothicBBB-Medium.Hankaku
sansserif.x11jis0201.bold=GothicBBB-Medium.Hankaku
#
monospaced.x11jis0201.plain=GothicBBB-Medium.Hankaku
monospaced.x11jis0201.italic=GothicBBB-Medium.Hankaku
monospaced.x11jis0201.bolditalic=GothicBBB-Medium.Hankaku
monospaced.x11jis0201.bold=GothicBBB-Medium.Hankaku
#
Обратите внимание. Авторы пытались впихнуть структуру параметров для каждого типа шрифта. Каждый ключ подцепил к себе суффикс. А теперь представьте себе, как усложнится парсинг этот-же файла, если для каждого элемента *italic надо будет задать еще один (опциональный) параметр "наклон шрифта".
P.S. Вспомнил интересный пример обращения с конфигом - в Solaris есть такая программка logadm. Программка уни кальна тем, что собственный конфиг она не только читает, но и пишет, поскольку в конфиге хранит, в том числе, и время своего последнего запуска и т.п. Программка при этом настолько погано написана, что, встретив ошибку в конфиге, как правило, валится в корку, при этом унося с собой конфиг (остаётся файл нулевой длины). Это к вопросу о том, что даже простейшю задачу некоторые товарищи "программисты" решают таким образом, каким решать её ну никак нельзя было. Что будет твориться с использованием сложного (а оно будет обязательно сложным) и мощного API работы с реестром, представить тяжело.
Я не помню случая, чтобы под Windows2k/2003 ПО само "разрушило реестр". Обычно это делал я сам, в пылу эксперимента и на правах локального админа удаляя кусты ключей
Мощное API , (ecли оно стоит своего громкого названия) не должно позволять на момент выполнения транзакции отсекать файл до нулевого размера.
