LINUX.ORG.RU
ФорумTalks

Реестр! Ы!


0

1

Шучу, не обязательно реестр...

Навеяно срачем не по теме в теме: http://www.linux.org.ru/forum/talks/5707291
«Пост гнева относительно /etc/бла-бла-бла.conf»

Почему когда речь заходит о конфигах и реестре, то oldschool'ные (а может и не oldschool'ные, а просто тролли) *nix'оиды посылают лечиться приверженцев реестра и других БД-образных конфигохранилищь?

То, что в винде реестр представляет собой неудобоваримое нечто еще не означает что нельзя сделать хорошо.
Обычно выдвигается аргумент типа «Текстовый конфиг можно править текстовым редактором».
А что бинарный нельзя? Можно сделать редактор который будет выглядеть как текстовый, будет маленьким и удобным, его без проблем можно будет использовать на том самом удаленном сервере, о котором так часто пишут oldschool'ные тролли.
Можно сделать текстовый интерфейс на уровне файловой системы (Например через FUSE или как часть ядра. Oldschool'ные тролли «Ааа... жуть... Реестр в ядре... Иди на семерочку!»). Пользователь сможет править конфиг как текст, программы будут работать через библиотеку, храниться может это все очень по-разному. Более того, можно будет сделать текстовый интерфейс с разным сиснтаксисом.

Какие я вижу плюсы:
- Равноправие текстового (или еще какого там)и графического конфигураторов. Если в этом, так называемом реестре, сделать схемы, то строить GUI можно будет быстро и просто, гораздо проще чем писать парсер конфига.
Хочешь GUI, а хочешь grep, sed и т.п.
- Легко связать со справкой даже для текстового интерфейса (см. пред пункт)
- Единый формат. Одни программы легко меняют конфиги других.

★★★★★
Ответ на: комментарий от Alsvartr

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

Как это?

Давай на конкретном примере. Найди какую-нибудь программу с конфигом в БД, выложи её конфиг, опиши последовательности действий для генерации этого конфига и копирования конфига в другую программу. И я поясню, какие именно моменты сложны для меня.

Реестр больше похож на текстовый файл, сжатый LZ, поэтому его не надо :)

Можно пример запроса к конфигам, недостижимого при помощи find-grep-sed?

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

Да? Пример: grep -ri eth0 /etc

Флаги ФС не используются, выдаст все упоминания eth0

Можно, например, искать информацию по тегам.

Что ты имеешь в виду под «тегами»?

Я не спорю, БД могут больше. Но нужны ли эти возможности здесь?

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

Подавляющее большинство файлов конфигов либо имеют то же имя, что и программа, либо лежат в директории с тем же именем. Не можешь запомнить и это?

А помнить значения каких-то полей БД всё равно придётся.

Лишняя сущность — каждый раз нужно придумывать запрос :)

Никакая это не лишняя сущность. С тем же успехом лишней сущностью могут быть и разные ключики и параметры к find-grep-sed.

Разумное возражение. Имхо, людей, которые что-то делают со stdin-stdout и регулярными выражениями всё же больше, чем регулярно работающих с SQL. А те, кто знаком со вторым обычно уже знают первое. Что касается noSQL: там надо каждую базу изучать заново, или есть какой-то стандарт?

question4 ★★★★★
()
Ответ на: комментарий от question4

> А те, кто знаком со вторым обычно уже знают первое. Что касается noSQL: там надо каждую базу изучать заново, или есть какой-то стандарт?

Вах , я так и не дождусь упоминания debconf у местных «мракобесов» ))

elipse ★★★
()
Ответ на: комментарий от question4

> А помнить значения каких-то полей БД всё равно придётся.

не факт.

[code]
Settings settings = new Settings()
settings.setScreenSize = new SettingScreenSize(640,480,32,59);
Registry registry = OS.getRegistry();
registry.save(«org.myapp.settings»,settings)
[/code]

а как это будет храниться - уже не мое дело. Как реализация реестра решит это хранить, так и будет.

stevejobs ★★★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.