Re: gconf2 на сервере
On Wed, Jul 02, 2003 at 12:07:29PM +0200, Sergey Spiridonov wrote:
> Vlad Harchev wrote:
>
> >On Wed, Jul 02, 2003 at 11:55:10AM +0500, Vlad Harchev wrote:
> >
> >>>>Жконф решает эти проблемы.
> >>>
> >>>Ой не надо, что что-то на букву g решает какие-то проблемы в сетевой
> >>>среде. Если уж Влад Харшев, большой апологет гнома и по-моему, активный
> >>>участник его разработки, высказался крайне пессимистично...
> >>
> >>:)
> >>
> >>Я по-большому счету не имею ничего против ИДЕИ (хотя есть конечно места
> >>где можно было еще концепцию улучшить).
> >
> >
> > А за наибольшую проблему в ИДЕЕ gconf я считаю отсутствие встроенного
> > понятия "текущий набор настроек" (профиль), которому в концепции
> >конфигурационных файлов соответсвтует сам конфигурационный файл.
>
> [snip]
>
> >общей гибкости. Если бы понятие профиля было поддерживаемо самим gconf'ом
> >то было бы на порядки лучше.
>
> Я бы всё же отнёс это к возможным доработкам, чем к недостаткам.
> По-моему профайлы дополнят идею жконф, и серьёзных изменений в концепции
> не требуют.
Нет, это надо было в самом начале договариваться - потому как сейчас
в приложениях исп-х gconf стоят вызовы с использованием полного пути
к ключу типа
gconf_get_bool("/desktop/gnome/general/double-click-timeout")
А это ИМХО сильно мешает использованию профайлов так как надо куда-то
ввернуть его имя.. Разве что как префикс..
> >
> > А второй проблемой gconf'а можно считать отсутствие понятия
> >"символьная ссылка" и "жесткая ссылка" (как в файловых системах). Но это
> >уже редко нужно.
>
> Это для случаев параметров, которые зависят от других? Тогда лучше не
> ссылка, а внутренний язык, типа guile. То есть я думаю, хорошим
> дополнением будет возможность писать хуки на, скажем гуиле, которые
> вызываются при изменении параметров и выполняют какие-то действия на
> стороне сервера.
Нет, это для случая нескольких профайлов, когда хочется чтобы для
профайла с именем blah брались из основного все настройки кроме какой-то
одной, а для этого достаточно иметь подобие симлинка (с одной ветки на другую,
так же и для ключей).
А при наличии языка будет проблема неоднозначности присвоения значний
из программы-конфигуратора.
> И это я бы отнёс к дальнейшим путям развития хорошей идеи, чем к
> недостаткам. В принципе, жконф это база данных, и наличие server-side
> языка поможет решать некоторые задачи, как, например PL/SQL в Оракле и
> Постгресе.
Ну в принципе симлинки можно ввести прозрачно для приложений уже потом,
так что их внедрению ничего не мешает и сейчас.
--
Best regards,
-Vlad
Reply to: