> Так что там с неэффективностью выкладывания иерархии в файловую систему?

У меня на это есть в песенке припев: "меня мало колышут детали реализации какого-то одного бекенда, даже если он дефолтный - меня интересует только интерфейс"

> Ато всплывает ещё одна проблема виндового реестра -- необходимость его подчищать.

Опять-таки, никто не мешает написать чистилку гконфа. Просто никому до сего дня было не нужно. Кстати, объясните - а почему в виндах надо чистить реестр? Только не говорите мне, что из экономии места.

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

Если уж так приспичит - тот же gconftool-2

>>Опять-таки, никто не мешает написать чистилку гконфа

написали ж, тут и новость была

А, точно, запамятовал, спасибо. Ну что, значит кому-то понадобилось. Хотя не очень понятно, зачем...

Re^16: Чем плох GConf?

>> Можно ещё, для закрепления, рассказать use case для двух перечисленных требований?

> Enterprise. Куча параметров могут быть устанавливаемы централизованно - от обоев до адреса прокси. И закрыть доступ к этим параметрам.

Общие слова. Я не придираюсь, просто хочу увидеть краткий, чёткий, реально нужный пример.

> держащего свой демон в памяти для хранения единственного на всю программу булевского значения

> Демон - не "свой" - а один на весь десктоп.

свой -- имелось в виду "демон хранителя конфигов"

> Централизованное управление и контроль - это ВОЗМОЖНОСТИ. Которые, кстати, в простейшей реализации отсутствуют - и соотв. ничего не стоят.

Ради этого программисты отказываются от хранения данных в их удобном domain-specific представлении.

> Но реализацию можно при необходимости усложнить - без изменения программ.

А много ли программ в том же гноме будут нормально работать, а не падать в корку, если им запретить писать в какой-то ключ конфига? Почти что уверен, что в 50% не проверяются коды возврата.

> "меня мало колышут детали реализации какого-то одного бекенда, даже если он дефолтный - меня интересует только интерфейс"

сферический интерфейс в вакууме?

> Кстати, объясните - а почему в виндах надо чистить реестр? Только не говорите мне, что из экономии места.

ну, насколько мне известно, по трём причинам:

1. он полностью загружается в память. от этого в сферическим gconf-e, ровно как и в сферическом реестре можно избавиться переписыванием бэкенда.

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

3. прочие проблемы связанные с записями в системных ключах.

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

> Если уж так приспичит - тот же gconftool-2

У него есть параметр --purge-config-files-for-deleted-programs ?

>> Опять-таки, никто не мешает написать чистилку гконфа

> написали ж, тут и новость была

гы, в следующем флейме отправлю гика чистить гконф :))

> Общие слова. Я не придираюсь, просто хочу увидеть краткий, чёткий, реально нужный пример.

Что может быть конкретнее адреса прокси? Что может быть конкретнее Kiosk Mode?

> Ради этого программисты отказываются от хранения данных в их удобном domain-specific представлении.

Программистам пофиг представление, если есть удобный API.

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

Не знаю. Попробуйте. Авторы API не несут ответственности за его кривое использование, если они сделали со своей стороны все, что могли.

Кстати, падать скорее всего никто не будет - просто пользователь будет удивляться, что он что-то меняет, а ничего не меняется. Но это действительно вопрос корректности использования API.

> сферический интерфейс в вакууме?

Вполне конкретный. Прост детали реализации - это мелочи. Говорю вам как жаваписец. Интерфейс - вот что важно.

> ну, насколько мне известно, по трём причинам:

Причины 1 и 2 - проблемы конкретной реализации. Неинтересно. Проблема 3 к gconf отношения не имеет. Когда появится системный gconf - посмотрим, сравним, обсудим.

> --purge-config-files-for-deleted-programs

Нет. И не нужно. Ибо нет возможности узнать на уровне gconf, что было удалено. А вот дистромейкеры могут сделать скрипт на случай apt-get purge, чтобы сносил настройки соотв. приложения. Если захотят. Но они почему-то не делают. Наверное, нафиг не сдалось (ибо перечисленные выше причины к gconf не относятся).

>> Общие слова. Я не придираюсь, просто хочу увидеть краткий, чёткий, реально нужный пример.

> Что может быть конкретнее адреса прокси?

Адрес прокси устанавливается один раз в proxy.company.com:3128, потом меняется запись в dns.

> Что может быть конкретнее Kiosk Mode?

kiosk -- это немного не enterprise.

>> Ради этого программисты отказываются от хранения данных в их удобном domain-specific представлении.

> Программистам пофиг представление, если есть удобный API.

Наиболее удобное API: configObject.save(); А для этого придётся как-то маппить внутренние типы на типы библиотеки для конфигов. Что не всегда легко (попробйуте замапить матрицу из многочленов). А уж если в библиотеке ипользуются строки glib::ustring, а в основном проекте -- std::string.... (причмокивая губами) какие там баги можно сваять...

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

> Не знаю. Попробуйте. Авторы API не несут ответственности за его кривое использование, если они сделали со своей стороны все, что могли.

Действительно удобное API сложно использовать криво.

> Адрес прокси устанавливается один раз в proxy.company.com:3128, потом меняется запись в dns.

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

> kiosk -- это немного не enterprise.

Это было через запятую.

> Наиболее удобное API

Давайте оставаться в С. А там ни объектов, ни рефлексии (впрочем, рефлексии и в плюсах толком нет).

> Действительно удобное API сложно использовать криво.

Давайте оставаться в С. Сколько приложений проверяют результат malloc на NULL?

> Прост детали реализации - это мелочи. Говорю вам как жаваписец. Интерфейс - вот что важно.

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

>> ну, насколько мне известно, по трём причинам:

> Причины 1 и 2 - проблемы конкретной реализации. Неинтересно.

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

>> --purge-config-files-for-deleted-programs

> Нет. И не нужно. Ибо нет возможности узнать на уровне gconf, что было удалено. А вот дистромейкеры могут сделать скрипт на случай apt-get purge, чтобы сносил настройки соотв. приложения. Если захотят. Но они почему-то не делают. Наверное, нафиг не сдалось (ибо перечисленные выше причины к gconf не относятся).

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

Кстати, придумал ещё один вариант, когда удаление конфигов нужно: если программа после изменения какого-то значения стала сегфолтиться на старте и пользователь хочет сбросить настрофки в дефолтные.

> любой интерфейс можно испоганить реализацией.

Хороший интерфейс плохой реализацией испоганить нельзя (потому что ее можно поменять).

> Мало кому в реальной жизни интересен интерфейс, если реализация подводит

Вот я как раз среди тех, кому он интересен.

> Это всё костыли, даже если они будут реализованы.

+0.5 (все-таки сам по себе gconftool-2 не является костылем). Почему костыли - потому что нафиг не нужны.

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

А что делать, если это так?

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

Фтопку такую программу. Не дело пользователя - заметать под коврик баги разработчиков. Кроме того, такие случаи чаще всего происходят в программах, где настроек слишком много и они бессистемны. В гномовских программах обычно набор настроек обозрим ("хиганут") и соотв. порушить неправильной конфигурацией их непросто.

Но, как я сказал, если таки приспичило - gconftool-2 придет на помощь.

>> Адрес прокси устанавливается один раз в proxy.company.com:3128, потом меняется запись в dns.

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

Неправильная постановка задачи. Надо чтобы это можно было в одну команду вернуть на место(а это делается копированием одного простого текстового конфигурационного файла). А то получим IE с неактивной кнопочкой "задать адрес прокси".

>> Наиболее удобное API

> Давайте оставаться в С. А там ни объектов, ни рефлексии (впрочем, рефлексии и в плюсах толком нет).

Ну это ещё лучше для меня :) Если рефлексии нет, то придётся её реализовывать. В итоге получим 50килобайтный файл, состоящий из строчек вида a=gconf_get_config("path/to/config","type",default_value); (синтаксиса не знаю, пишу интуитивно).

>> Действительно удобное API сложно использовать криво.

> Давайте оставаться в С. Сколько приложений проверяют результат malloc на NULL?

Я думаю, что их число не более чем на порядок превосходит число приложений, которые криво работают с gconf.

Кстати, для примитивных типов всё можно сделать макросами, в которые встроить проверку на тот же NULL. Но и у них есть свои проблемы.

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

> Хороший интерфейс плохой реализацией испоганить нельзя (потому что ее можно поменять).

Угу, получив DE в полгода :)

>> Мало кому в реальной жизни интересен интерфейс, если реализация подводит

> Вот я как раз среди тех, кому он интересен.

А я -- пользователь.

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

> А что делать, если это так?

А я упёртый пользователь. Можно ведь и мусор из дома не выносить, он ведь много места не занимает.

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

> Фтопку такую программу. Не дело пользователя - заметать под коврик баги разработчиков.

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

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

Грязный пиар гнома :)

> Но, как я сказал, если таки приспичило - gconftool-2 придет на помощь.

Ну так где мои волшебные ключики для gconftool, которые мне помогут вычистить конфиг гнумерика?

> А то получим IE с неактивной кнопочкой "задать адрес прокси".

Да, именно этого и хочется. Это и есть use-case.

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

А куда деваться? В С иначе не получится при любом раскладе. Да, default_value не нужно - оно прописывается в схему gconf. Насчет 50К - нефиг столько конфигурационных параметров заводить. Помним про HIG ;)

> А уж с непримитивными типами вообще редкостно большое поле граблей обозначается.

Если Вы хотите меня убедить, что С - низкоуровневый язык, то я заранее согласен. Именно поэтому любой API на C может быть применен неправильно, соотв. Ваше утверждение "хороший API сложно применить неправильно" оставьте для любителей всяких хаскелей да окамлов. В языке С это не так.

> А я -- пользователь.

Для Вас все необходимые средства предусмотрены. А что у вас идиосинкразия на месте текстовых файлов и sed/awk - разработчики gconf не виноваты.

> А я упёртый пользователь.

Белый шериф по-прежнему внимателен к афроамериканцам...

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

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

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

http://linux.die.net/man/1/gconftool-2

>> А то получим IE с неактивной кнопочкой "задать адрес прокси".

> Да, именно этого и хочется. Это и есть use-case.

То есть моя трактовка "быстро вернуть всё как было" категорически отметается?

> Именно поэтому любой API на C может быть применен неправильно, соотв. Ваше утверждение "хороший API сложно применить неправильно" оставьте для любителей всяких хаскелей да окамлов. В языке С это не так.

Что легче сделать в то же C: прочитать файл или распарсить xml? Это не к конкретному способу хранения настроек, это к удобному и лаконичному API. Напутать что-то в 3 функциях гораздо менее вероятно чем в 150.

> А что у вас идиосинкразия на месте текстовых файлов и sed/awk - разработчики gconf не виноваты.

Я просто не буду использовать их продукт.

> Белый шериф по-прежнему внимателен к афроамериканцам...

Потому негры и используют в повседневной жизни kde :)

> http://linux.die.net/man/1/gconftool-2

надо же, всего на четвёртой странице мне сказали про --recursive-unset!

> Именно поэтому любой API на C может быть применен неправильно, соотв. Ваше утверждение "хороший API сложно применить неправильно"

И в продолжение темы "правильного" API. Во времена становления теории дифференциальных уравнений существовало 2, так сказать, API для записи: в виде рядов и в виде dx/dt. Думаю, не стоит говорить, какой именно метод выжил и почему в нём меньше места для ошибок и больше фундамент для последующих наработок.

> То есть моя трактовка "быстро вернуть всё как было" категорически отметается?

Да. Потому что исправить траблу (даже если это один клик мышкой) сложнее, чем просто уничтожить условия ее появления. Профилактика проблем предпочтительней удобного траблшутинга (хотя и не отменяет его).

> Что легче сделать в то же C: прочитать файл или распарсить xml?

Бессмысленный в данном контексте вопрос. Само приложение не парсит xml. Его парсит бекенд. Отлаженный, поддерживаемый. И в этом смысле на порядок менее проблемный, чем наколеночный парсер очень крутого и очень текстового формата, по-быстрому сляпанный в С каким-то красноглазым "гуру".

> Напутать что-то в 3 функциях гораздо менее вероятно чем в 150.

И что? Давайте теперь все ограничимся написанием разных вариантов hello world. Если нужна сложная функциональность - будет сложный код. Это не конец света. Или Вы против высокоуровневых API как таковых?

> Я просто не буду использовать их продукт.

Ваше право.

> Потому негры и используют в повседневной жизни kde :)

Наверное, по неведению. Ибо в kde очень похожая фигня, как уже установлено аналитиками ЛОРа.

> надо же, всего на четвёртой странице мне сказали про --recursive-unset!

Извините, я до последнего надеялся на Ваше умение пользоваться гуглом. Но однажды сдался... Закрываем тему очистки реестра?

Стоит говорить. А также стоит немного подробнее разъяснить аналогию, а то я за поздним часом не улавливаю...

>> То есть моя трактовка "быстро вернуть всё как было" категорически отметается?

> Да. Потому что исправить траблу (даже если это один клик мышкой) сложнее, чем просто уничтожить условия ее появления. Профилактика проблем предпочтительней удобного траблшутинга (хотя и не отменяет его).

Подобная профилактика зачастую только мешает. Например, видеть при каждом запуске эклипса 2 окошка "registry editing has been disabled by system administrator" неприятно.

Да и, к тому же, пока что(к счастью) не все программы обладают подобным функционалом. И потому пользователь, у которого в IE закрыты все настройки, будет ставить себе оперу, на которую подобные ограничения не действуют. Ах да, поставить ему её тоже права не дадут... Ну на это достаточно напомнить, что рабский труд нерентабелен :)

>> Что легче сделать в то же C: прочитать файл или распарсить xml?

> Бессмысленный в данном контексте вопрос. Само приложение не парсит xml. Его парсит бекенд. Отлаженный, поддерживаемый. И в этом смысле на порядок менее проблемный, чем наколеночный парсер очень крутого и очень текстового формата, по-быстрому сляпанный в С каким-то красноглазым "гуру".

Вы меня удручаете. Я ведь специально написал "Это не к конкретному способу хранения настроек".

Есть 2 API: сложное, многофункциональное, навороченное, у которого 150 функций и короткое, в 5 функций другое, в котором есть сохранялся только для пары примитивных типов. И программа, которая оперирует только примитивными типами, будет содержать меньше места для ошибок. Вот тут снова всплывает сравнение молотка и микроскопа.

> Или Вы против высокоуровневых API как таковых?

Я против вредной унификации.

> Стоит говорить.

Большинство соотношений, особенно в физике, сейчас принято записывать в дифференциальной форме. d^2(m x)=F

> А также стоит немного подробнее разъяснить аналогию, а то я за поздним часом не улавливаю...

Аналогия: сложное в использовании многофункциональное api, как запись решения д.у. в виде ряда и простенькое, не всегда дающее ответ даже в квадратурах(в таких случаях приходится сводить к сложному), но удобное и короткое api с дифференциалами.

>> Потому негры и используют в повседневной жизни kde :)

> Наверное, по неведению. Ибо в kde очень похожая фигня, как уже установлено аналитиками ЛОРа.

Приходится выбирать меньшую какашку.

> Извините, я до последнего надеялся на Ваше умение пользоваться гуглом.

Я даже на страничке не сразу нашёл, т.к. искал по словам delete и purge. Потом начал читать подряд.

> Закрываем тему очистки реестра?

Теперь - да. Н не надо говорить, что оно не нужно.

> Например, видеть при каждом запуске эклипса 2 окошка "registry editing has been disabled by system administrator" неприятно.

Это вопрос к эклипсу, не к реестру.

> Ну на это достаточно напомнить, что рабский труд нерентабелен :)

Это не рабство, это корпоративная IT Policy. Такое бывает. А дома извращайтесь как хотите. Про нерентабельность - расскажите это фирме IBM, которая запрещает своим сотрудникам установить ЛЮБУЮ нестандартную программу, не "пробив" этот вопрос с соотв. менеджерами.

> И программа, которая оперирует только примитивными типами, будет содержать меньше места для ошибок.

И что? Вы сравниваете программы с разной функциональностью. Я - модули программы, отвечающие за одно и то же - сохранение и чтение конфигурации. И то, что уже работает и отлажено в gconf, придется заново программировать и отлаживать в каждой конкретной программе, только потому что для нее есть только fopen/fscanf/fclose.

> Я против вредной унификации.

Я тоже против вредной. Я за полезную.

ЗЫ Походу, очень странно видеть человека, работающего с жабой - и не понимающего важность и пользу универсальных высокоуровневых интерфейсов.

Пример понял - но аналогию считаю некорректной. Ибо Вы сравниваете API одного уровня, хотя и разной сложности. Мы же с Вами сравнивает API разных уровней.

> И то, что уже работает и отлажено в gconf, придется заново программировать и отлаживать в каждой конкретной программе, только потому что для нее есть только fopen/fscanf/fclose.

Ну да, code reusion. Мне приходилось наблюдать, какие чудовищные вещи творят люди, дабы только не написать два сервлета в 20 строчек вместо одного. Всё хорошо в меру, в т.ч. важен баланс реюзинга и велосипедов.

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

> ЗЫ Походу, очень странно видеть человека, работающего с жабой - и не понимающего важность и пользу универсальных высокоуровневых интерфейсов.

Абстракции хороши в меру и без надобности их плодить -- только во вред.

<тут могла быть цитата про излишний уровень абстракции>

> Ибо Вы сравниваете API одного уровня, хотя и разной сложности.

Я специально упомянул про случаи, когда "простого" API недостаточно. Не всё интегрируется в квадратурах.

> Мы же с Вами сравнивает API разных уровней.

Уровень один: сохранить и получить конфиги. Остальное -- от лукавого.

Кстати, интересно, а почему разрабы gnome хотят заменить gconf на GSettings/dconf?

У меня есть несколко вариантов:

У меня есть несколко вариантов:
1. Избавление от bonobo/ORBit
2. Ввести единую систему конфигурации и мониторинга в GTK.
3. Избавить многие приложения от привязки к Gnome

> Всё хорошо в меру, в т.ч. важен баланс реюзинга и велосипедов.

Важен. Так где в Вашем случае этот баланс? Если Вы подымаете уровень абстракции и вводите libconfig (и мы забываем файловые операции) - тогда давайте сравнивать возможности, предоставляемые libconfig и gconf. Создадим два списочка и прикинем..

> Абстракции хороши в меру и без надобности их плодить -- только во вред.

Я вижу конкретную надобность в абстракции gconf. Соотв. вреда - нет.

> Уровень один: сохранить и получить конфиги. Остальное -- от лукавого.

Бред. Уровень файловых операция сильно ниже уровня конфигурационного API. То, что файловые операции могут использоваться для реализации конфигурационного API - не ставит их на тот же уровень. Или Вы будете утверждать, что сокеты и CORBA - это API одного уровня? Тогда я, извините, буду вынужден искренне пожелать (послать) Вас почитать книжки какие-нибудь.

Re^18: Чем плох GConf?

>> Уровень один: сохранить и получить конфиги. Остальное -- от лукавого.

> Бред. Уровень файловых операция сильно ниже уровня конфигурационного API. То, что файловые операции могут использоваться для реализации конфигурационного API - не ставит их на тот же уровень.

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

А что - сильно хотят? Пока что на странице dconf говорят "You probably don't want to use this yet."

Re^18: Чем плох GConf?

> тогда давайте сравнивать возможности, предоставляемые libconfig и gconf. Создадим два списочка и прикинем..

Правило 80/20 напонить?

> Я вижу конкретную надобность в абстракции gconf. Соотв. вреда - нет.

А я вижу вред. Ибо "универсальный формат" настолько же бесполезен и неудобен, насколько всеобщ.

Хотят это сделать в gnome 2.14
Походу будет также, как и с gio/gvfs

> Пусть будет либа. Вернее, пусть будет ного хороших и разных либ, из которых можно и нужно в каждом конкретном случае. Ключевое слово -- разнообразие.

Это кошмарное слово для обсуждаемой области. В результате имеем бардак /etc. На досуге можете посчитать кол-во парсеров, необходимых для Вашего /etc. Нужна единая система управления конфигурацией. ОДНА. Все остальное называется словом "бардак". Уже упоминавшийся эппл победил этот бардак. Чего и линуху желаю. Хотя, конечно, линуху это будет сложнее. Но в рамках одного десктопа это вполне реально, что и наблюдаем. А если будет решение от fd.o - тогда оба десктопа будут использовать единую архитектуру, что совсем здорово. И никакого бардака.

Re^18: Чем плох GConf?

> Хотят это сделать в gnome 2.14

Гы... Вылезайте из анабиоза, уже 2.22 вышел :)

> Правило 80/20 напонить?

Никто никогда из этого правила не делал вывода, что 80% не нужны.

> Ибо "универсальный формат" настолько же бесполезен и неудобен, насколько всеобщ.

Альтернативой является бардак.

Блин опшибся - 2.24

А ссылочкой не поделитесь?

Непомню, гдето видел. Кстати в RoadMap это тоже сказано.

Re^20: Чем плох GConf?

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

И что? Пользователь туда лазать руками не должен -- у него есть/могут быть утилитки.

> Нужна единая система управления конфигурацией. ОДНА. Все остальное называется словом "бардак".

Вы против DSL?

Погуглил я по dconf. Как-то это все выглядит невылупившимся цыпленком. К тому же есть ощущение, что это не замена gconf, а дополнение - как раз для хранения информации не пользователя, но системы (глобальный /etc) Впрочем это все еще горячо-сыро...

Кстати может и передумают, имея болезненный опыт перехода на gio.

Время ещё есть. Может и допилят до нормального состояния. Но вот процесс перехода будет долгим.

> Пользователь туда лазать руками не должен -- у него есть/могут быть утилитки.

Вы издеваетесь? Сколько утилиток надо для менеджения всех форматов в /etc? Посмотрите на несчастных людей, делавших linuxconf (почивший), webadmin и пр. Им приходится использовать отдельный парсер на каждый файл в /etc. И следить за тем, не поменял ли автор формат (например, от первого апача ко второму).

> Вы против DSL?

За. Только за. Я только доменом считаю конфигурацию. Это один домен. И DSL в данном случае - параметры командной строки gconftool-2.

В общем, пожуем-увидим;)