И это понятно, потому что они
содержат в себе парсер (бакэнд), который отличается от парсера
программы, файл которой они пытаются конфигурировать.
Каждая из программ которую они пытаются отконфигурировать, имеет свой
способ оповещения об изменениях, свой формат конфигурационных файлов,
свой парсер (и свои ошибки в нём) и т.д.
если уж очень нуже дополнительный конфигуратор, который буде работать с
конфигом заданного приложения, можно воспользоваться тем же парсером, который
использует это приложение...
С помощью идеи заложенной в жконф можно использовать одну(!) стандартную
утилиту, которая всегда будет соответсвовать версии и формату, потому
что она не знает, и не должна о формате конфигурационного файла.
В винде такая утилита уже есть --- зовут regedit. лично я считаю, что bash +
rtfm + mc + mcedit намного удобнее. или Вы считаете, что должно быть
диалоговое окно с большим количеством закладок, менюшек, списков, кнопок и
прочей тому подобной хрени? это же каких размеров должен быть этот диалог???
(видели, сколько записей в масдайном реестре???) проблему потерянной галочки
это только усугубит
Жконф
инкапсулирует эту информацию. Именно жконф (а точнее системный
администратор) определяет, какой формат будет использован
а это в свою очередь означает, что соответсвующий код никуда не делся, он
просто перекочевал в gconf...
(что позволяет
при желании использовать текстовые конфигурационные файлы, пригодные для
ручной правки).
не пойму какой тогда смысл в gconf? зачем тогда нужна эта "прокладка"?
Он также стандартизует способ оповещения,
а это еще что такое?
вводит возможность удалённого конфигурирования и проч.
удаленное администрирование итак прекрасно выполняется --- ничуть не хуже, чем
локальное
PS есть очень хорошая книжка:
Ален И. Голуб. С & С++. Правила програмирования. --- М.: БИНОМ 1996г. ---
272с.
очень рекомендую почитать, а пока я приведу несколько правил от туда, которые
имеют отношение к теме нашего разговороа:
1) сущьность програмирования: без сюрпризов, минимум сцепления, максимум
согласованности.
2) Подавляйте демонов сложности
2.1) Не решайте проблем, которых не существует
2.2) Решайте конкретную проблему, а не общий случай
4) не путайте легкость в изучении с легкостью в использовании
8) Разлагайте сложные проблемы на задачи меньшего размера
9.1) Используйте для работы соответствующий инструмент
10) Проблема должна быть хорошо продумана перед тем, как она сможет быть
решена,
14) Малое --- это прекрасно. (Болшое == медленное!)
я думаю, что все это достаточно актуально и сегодня
Кстати, qmail на моей машине (четвертый пень 1.7 гига, 512 метров мозгов) в
первый раз грузится секунд 15 а то и больше :-( лет семь назад, когда у меня
был сотый пень с 32 метрами у меня практически все летало...
Еще одно наблюдение
в 1995 на четверке DX2-66 с 8 метрами мозгов сборка ядра занимала около 20
минут. Сейчас на моей машине (см выше) сборка ядра занимает около 4 минут и
это с учетом того, что машина стала круче боле чем в 25 раз !!! вот вам и
прогрес :-(
PSS почему /etc это хорошо
/etc --- это один из краеугольных камней, на которых стоит UNIX. фактически
это опыт, накопленный более чем за тридцать лет его эксплуатации. практически
все программы расчитаны на работу с /etc и для перехода на gconf их все
придется переписать. при этом неизбежно большое количество багов.
API у gconf насколько я понимаю еще не устаялся, потребуется достаточно
большое количество времени, пока станет ясно, что там надо, а что нет.
написание програм, расчитанных на gconf, требует специального подхода. при
разработке уже существующих программ соотвествующие требования естественно не
учитывались, следовательно их переделка совсем не тривиальная задача.
Существует достаточно большое количество приложений конфиги которых нереально
запихнуть в gconf ярчайший пример это senmail, senmail.cf это вообще легенда
UNIX тем не менее алгоритм работы senmail'а очень крепко привязан к этому
конфигу.
Следующий не менее яракий пример --- это emacs там весь конфиг на elisp'е.
кроме того идет большое количество скриптов на bash, perl и тд и тп, которые
либо сами по себе являются конфигами, либо используют другие скрипты в
качестве конфига. конечно можно сделать специальный API для доступа к
содержимому gconf. но конструкции типа include намного проще и надежнее в
этом случае
РЕЗЮМЕ:
Вобщем-то вполне наверно можно заменить /etc на gconf, но это уже будет не
UNIX а какая-то другая система. и вобщем-то подобная система уже есть --- M$
winddows и скажу честно, что уменя ее администрирование вызывает большое
раздражение (по этому я им и не занимаюсь) и я не верю, что вариант gconf
будет намного лучше...