LINUX.ORG.RU

В XFCE тоже будет реестр

 


0

0

В грядущем релизе 4.6 будет использоваться новая система конфигурирования xfconf, по архитектуре похожая на gconf и состоящая из компонентов, взаимодействующих с помощью dbus.

>>> Обзор со скриншотами

>>> Подробности

★★★★★

Проверено: anonymous_incognito ()
Ответ на: комментарий от anonymous

Re^4: В XFCE тоже будет реестр

> ...или меню для DM. Уже смысл есть.

Меню и так хранится в донельзя стандартизированном формате .desktop-файлов. Между прочим, на основе ini.

> Тот-же крон благодаря этому можно былоб редактировать из GUI не боясь потерять свои комменты... Да и по сетки CRON на 100 машнах настраивать за раз....


Используй pssh и разом обновишь файлы хоть на 1000 машин.

> Например по деклоративному конфигу можно автоматически строить диалог preferences...


Можно, но он будет безнадёжно неудобен. Пример: окно настройки прокси, в котором поля "логин" и "пароль" должны быть активными только если галка на поле "авторизация" выставлена и неактивны в противном случае. А конфиг, хранящий эти описания -- уже не декларативный.

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

> Я вообще не понимаю, почему народ настолько зациклился на XML? Неужели его парсить сильно сложнее c-style конфигов, как у bind или dhcpd? В то же время такие конфиги гораздо читабельнее и легче редактируются обычним текстовым редатором.

> Если продолжить дальше - что плохого в ini-файлах, если настройки простые? Что плохого в файлах, где колонки разделяются пробелами или табами или двоеточиями? Что плохого в файлах где в каждой строке разделённые пробелом пары ключ-значение?

> Парсить неудобно? Парсеров много надо? Хочется чтоб "глобально и надёжно"? Тогда всё ясно - это просто быдлокодерство. Только быдлокодеры думают о себе, а не о пользователях.

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

Так уже написана такая универсальная библиотека называется - gconf. Даже кэширование предусмотрено. а в каком формате конфиг - дело back-end'a. А его уж можно натравить хоть на .ini файл ;)

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

В компании xml - корпоративный стандарт. Все остальное Ф топку ;)

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

> Видимо потому, что ручками править конфиги в SQL еще хуже чем в XML

да вот хрен знает на самом деле.. или SQL запрос дать/phpMyadmin каконить или mysql-navigator запустить или в некоторых случаях с XML конфигом разобраться. Зато сразу - удаленное конфигурирование рабочих станций, репликация конфигурации, загрузка и сохранение конфигурации в центральном хранилище, да и конфигуратор написать в каком-нить Lazarus как два пальца об асфальт.

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

> угу, все написали по патчу к exo. Похоже что разработчик libexo не родной остальным разрабам XFCE :) Вот на это и забили... судя по всему никаких изменений в exo на этом фронте не предвидится.

точно и жаль.

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

> да вот хрен знает на самом деле.. или SQL запрос дать/phpMyadmin каконить или mysql-navigator запустить или в некоторых случаях с XML конфигом разобраться. Зато сразу - удаленное конфигурирование рабочих станций, репликация конфигурации, загрузка и сохранение конфигурации в центральном хранилище, да и конфигуратор написать в каком-нить Lazarus как два пальца об асфальт.

Спешите видеть: настоящий, живой дельфибыдлокодеришко на ЛОРе! С рук не кормить!

anonymous
()
Ответ на: Re^4: В XFCE тоже будет реестр от gaa

>Можно, но он будет безнадёжно неудобен. Пример: окно настройки прокси, в котором поля "логин" и "пароль" должны быть активными только если галка на поле "авторизация" выставлена и неактивны в противном случае. А конфиг, хранящий эти описания -- уже не декларативный.

Фигня... наследование для этого и придумали. Отнаследовался от него и 2,3 обработчика и параметра допинал... А если как в gconf формат еще и подсказки дает, да еще и пределы....

anonymous
()
Ответ на: комментарий от VoDA

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

>В компании xml - корпоративный стандарт. Все остальное Ф топку ;) VoDA (*) (18.09.2008 17:33:11)

Пока ты тут "фтопкаешь" пришла новость об универсальной либе parse_conf, которая освобождает быдолкодеров от необходимости напрягать свой миниатюрный моск для написания парсеров стандартных юниксовых текстовых конфигов.

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

>И получим нечто вроде /.\|*[A-z]!# итак на 4 страницы......

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

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

>Оно конечно не избавит от случаев с кучей ифоф.... Но едим, же этот кактус сейчас.


Если ты об обработке умолчаний - посмотри всё-таки на FreeBSD, там есть два чистеньких файла /etc/rc.conf - для настроек конкретно этой системы, /etc/default/rc.conf - для умолчаний.

>Не, ну я понимаю grep, sed, awk... Но когда они покаждому иху стартуют по 500 штук, и все из-за того, что конфиг кто-то меняет.


Объясните мне тупому, зачем редактировать конфиг из программы на shell'е. Если это конфиг - его редактируют в текстовом редакторе руками. Если это мастер настройки - на кой чёрт его писать на shell'е? Если данные так часто необходимо менять из программы - это не конфиг, а файл данных или база данных.

>А завтра захочется цифровые подписи в конфиг писать, ну чтоб хакер не поменял конфиг апача незаметно. Что делать будете?


Ну не пиздец а? Вы о tripwire слышали когда-нибудь? О md5-хэшах, которыми сверяют правильность скачанных iso-образах? О цифровых подписях gpg? Явно нет, считаете себя самым умным, поэтому изобретаете свой велосипед.

> А если часть конфига надо разрешить менять, а инклюда автор конфига не предусмотрел?


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

>Да много еще полезностей есть, только вам не осилить.


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

>Раньше были люди пихающие XML куда не надо (голос, 3Д), теперь структурированное иерархическое хранилище это мол не его предназначение.... Ну, ну


Вы вообще мои возражения читали? Я не возражаю против хранения часто изменяемой информации в xml, я возражаю против xml в конфигах!

morbo
()
Ответ на: комментарий от VoDA

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

Лентяев нужно при рождении убивать. Вам жить ещё не лень?

>В компании xml - корпоративный стандарт. Все остальное Ф топку ;)


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

morbo
()
Ответ на: комментарий от anonymous

>>Можно, но он будет безнадёжно неудобен. Пример: окно настройки прокси, в котором поля "логин" и "пароль" должны быть активными только если галка на поле "авторизация" выставлена и неактивны в противном случае. А конфиг, хранящий эти описания -- уже не декларативный.

>Фигня... наследование для этого и придумали. Отнаследовался от него и 2,3 обработчика и параметра допинал... А если как в gconf формат еще и подсказки дает, да еще и пределы....


Писец. Живой быдлокодер-индус на ЛОРе! Для этого в императивных языках придумали оператор if!

morbo
()
Ответ на: комментарий от anonymous

Re^6: В XFCE тоже будет реестр

>>Можно, но он будет безнадёжно неудобен. Пример: окно настройки прокси, в котором поля "логин" и "пароль" должны быть активными только если галка на поле "авторизация" выставлена и неактивны в противном случае. А конфиг, хранящий эти описания -- уже не декларативный.

> Фигня... наследование для этого и придумали. Отнаследовался от него и 2,3 обработчика и параметра допинал... А если как в gconf формат еще и подсказки дает, да еще и пределы....


А обработчики этого ты собираешься хранить, как и долбоебы из gconf team, в конфиг-файле?

gaa ★★
()
Ответ на: Re^6: В XFCE тоже будет реестр от gaa

>А обработчики этого ты собираешься хранить, как и долбоебы из gconf team, в конфиг-файле?

На самом деле ничего плохого тут нет. Еще в 80 каком-то году люди стремились к исполняемым документам - смотри в сторону FramerD.

И не надо путать теплое с мягким. Никто не предлагал записывать XML файл по 1000 раз в секунду. Демон для того и придумали.

Конфиг, хороший конфиг, а не ту RC хрень о которой вы говорили можно редактировать 1) Руками в текстовом редакторе 2) С помощью GUI 3) Программа должна уметь его править.

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

>И не надо путать теплое с мягким. Никто не предлагал записывать XML файл по 1000 раз в секунду. Демон для того и придумали.

Настройки потерять не боишься? :D

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

>Конфиг, хороший конфиг, а не ту RC хрень о которой вы говорили можно редактировать


RC-хрень предложил не я, а анонимный разум. Я привёл пример когда конфиги являются одновременно и rc-файлами, они наглядны и удобны для редактирования (файлы /etc/rc.conf FreeBSD).

>1) Руками в текстовом редакторе 2) С помощью GUI 3) Программа должна уметь его править.


По первому пункту. Принципиальная возможность править xml руками в текстовом редакторе есть, но это не удобно.

По второму пункту. С помощью GUI можно и двоичные файлы хорошо править. Давайте тогда конфиги в двоичных файлах хранить. А как GUI накроется будем разводить руками или извращаться с редактированием из другой системы.

По третьему пункту. См. пункт второй.

morbo
()
Ответ на: комментарий от anonymous

Re^8: В XFCE тоже будет реестр

>>А обработчики этого ты собираешься хранить, как и долбоебы из gconf team, в конфиг-файле?

> На самом деле ничего плохого тут нет. Еще в 80 каком-то году люди стремились к исполняемым документам - смотри в сторону FramerD.


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

gaa ★★
()
Ответ на: Re^8: В XFCE тоже будет реестр от gaa

>То есть внезапно конфиг из статического набора двнных становится интерпретируемым, причем только в одном месте эта интерпретация нужны -- в GUI. Мама не учила разделять код, делающий разные вещи?

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

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

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

По моей логике идиот - ты. Ты и в конфигах будешь хранимые процедуры размещать?

morbo
()
Ответ на: комментарий от anonymous

Re^10: В XFCE тоже будет реестр

>>То есть внезапно конфиг из статического набора двнных становится интерпретируемым, причем только в одном месте эта интерпретация нужны -- в GUI. Мама не учила разделять код, делающий разные вещи?

> Разделять надо код и представление...


И это тоже.

> По вашей логике те кто изобрели хранимые процедуры и триггеры идиоты...


А вот неправильно ты эмулируешь мою логику.

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

2morbo

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

И если есть возможность придуматьсредство не позволяющее в переменную ip_address вбить 327.265.455.999, то любой нормальный человек будет это только одобрямс... Ясен пень в идеале надо делать такую фишку необязательной.

Но это я мечтаю. (хотя скажем JS проверки можно организовать, типа триггеров). Но как например FireFox игнорирует DTD ошибки, это надо делать отключаемым

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

опять-же, вот положим ты заводишь новый почтовый аккаунт в мозилле. Тебя спрашивают smtp адрес. Ты хочешь ввести mysuperdomainserver.ru, ошибаешься и вводишь musuperdomanserver.ru. Потом ты вводишь номер порта (хорошо, хорошо - он по умолчанию), выбираеь ssl/tls вводишь имя, пароль, жмешь ок 5 раз и ничего не работает...

Почему-б в конфиге не предусмотреть warning(resolve(hostname),'Хост не найден');

Он ещеб на этапе ввода имени хоста сказа-бы улюлю...

Окей - пусть это ini файл в котором есть параметр checker=my_hecker.js

После правки в своем любимом ed или с помощью sed ты говоришь validate my_config.conf И вуаля - он тебе warining host in variable smtp_server not resolving.

Что в этом плохого? Дарю идею.

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

>Почему-б в конфиге не предусмотреть warning(resolve(hostname),'Хост не найден');

Идея дебильная по своей сути. Все секюрити идет в женский половой орган. Не хватало еще троянов из xml-конфигов вылавливать. Кому-то лавры мелкомягких "новаторов" не дают покоя.

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

>Идея дебильная по своей сути. Все секюрити идет в женский половой орган. Не хватало еще троянов из xml-конфигов вылавливать. Кому-то лавры мелкомягких "новаторов" не дают покоя.

Кто тебе подкинет конфиг? Ты о чем?

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

Отвечу просто подправленной цитатой

>Окей - пусть это ini файл в котором есть параметр checker=http://fuck-mosk.com/my_hecker.js

"my_hecker.js" - классная ачепятка у тебя вышла

а RC-файлы и так являются желанной целью хакеров и головной болью сиссадмина, как и все содержимое /etc. Ты ему просто предложил совершить ритуальное самоубийство в извращенной форме, снабдив конфиги активным компонентом ради мифического "удобства".

И еще, ты понимаешь разницу между *скриптами* инициализации системы и *конфигами* прикладных программ - коих легион?

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

>И еще, ты понимаешь разницу между *скриптами* инициализации системы и *конфигами* прикладных программ - коих легион?

Ага понимаю. Потому и говорю, что RC это зло. Активный компонент не обязан быть активным. Тоесть никто не мешает написать интерпритатор без файловых функций и прочего. Считать - да пусть читает. Записать, не надо.

Муфические удобства дадут большой бонус. Ты сможешь конфигурировать тысячи машин одним движением пальца и получать сообщения, что на машинах a,b,c твои конфиги неприменимы. Причем сразу, а не когда апач ляжет.

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

>>И еще, ты понимаешь разницу между *скриптами* инициализации системы и *конфигами* прикладных программ - коих легион?

>Ага понимаю. Потому и говорю, что RC это зло.

Да нихрена ты не понимаешь.

> Активный компонент не обязан быть активным. Тоесть никто не мешает написать интерпритатор без файловых функций и прочего. Считать - да пусть читает. Записать, не надо. ...[поскрипано]

Бред какой-то..., поток альтернативного сознания, блин! Вот уж кому логопед не помешал-бы.

Виктор Степанович, залогиньтесь!

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

>Да нихрена ты не понимаешь.

Ага, так-же как и создатели самбы. У них вообще активный компонент на C написан. testparm называется.... Ну идиоты, что с них взять?

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

>Почему-б в конфиге не предусмотреть warning(resolve(hostname),'Хост не найден');

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

>Он ещеб на этапе ввода имени хоста сказа-бы улюлю...


Это подход удобен для пользователя. Пользователю же удобно сносить все настройки если что-то поломалось. Мне удобнее починить.

>Окей - пусть это ini файл в котором есть параметр checker=my_hecker.js


>После правки в своем любимом ed или с помощью sed ты говоришь validate my_config.conf И вуаля - он тебе warining host in variable smtp_server not resolving.


>Что в этом плохого? Дарю идею.


Ты изобрёл колесо и решил подарить его мне? Во всех вменяемых программах конфиг проверяется перед запуском с подробной диагностикой - что не так. У некоторых бывает отдельная опция для проверки конфига или отдельная утилита валидации.

morbo
()
Ответ на: комментарий от anonymous

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

Никто не мешает написать интерпретатор для изначально неактивного конфига.

>Муфические удобства дадут большой бонус. Ты сможешь конфигурировать тысячи машин одним движением пальца и получать сообщения, что на машинах a,b,c твои конфиги неприменимы. Причем сразу, а не когда апач ляжет.


Мусье фантаст? Предлагаю написать такую систему, потом обсуждать. В любом случае такая функциональность встроенная в конфиг мне не нужна.

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