[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gconf2 на сервере



Alexander Danilov wrote:

[snip]

unix вариант мне нравится тем, кто в файлах конфигов есть комментарии(debian
здесь на высоте) и документация в районе /usr/share/doc или /usr/doc, windows
вариант не нравиться тем, что комментариев нет, а о смысле ключей можно
только догадываться, а о значениях ключей порой и догадываться нельзя.
Я уже молчу о том, что непонятно, как узнать о том, какие ключи можно
создавать для конкретных приложений и системы. Об этом наверно только на MSDN
и можно узнать.

в то же время мне понятна причина появления этого треда и я также устал
смотреть на файлы конфигурации в своем каталоге:

$ ls -a1|grep "^\." | wc -l
	205

но я потихоньку стараюсь перетащить их в ~/etc

gconf я запускал, сюдя по всему, это тот же regedit с новыми возможностями(я
наверно ошибаюсь), т.е. есть название ключа, есть его значение, а комментарии
по поводу ключей где? а список возможных значений где? а список возможных
ключей где? а нигде! их нет! чем тогда он принципиально отличается от regedit?

Почитайте здесь http://developer.gnome.org/doc/API/gconf/index.html.
В introduction рассматриваются проблемы Windows-registry и как они решаются в gconf.
Есть там и комментарии и возможность ввести ограничения (проверку).
Пока совсем простые проверки, но более сложные можно будет ввести без изменения API.

Пока проблема комментариев не будет решена в надстройках, предназначенных для
конфигурирования, я буду голосовать за vim :)

Решена она, насколько я знаю. Есть подсказки и описания.

механизм оповещения я понял, но не понял зачем он нужен. темы менять в
распределённой среде?

Ну как же. Изменились настройки апача в конфигурационном файле, что нужно сделать? Перезапустить или послать сигнал ему чтобы он перечитал. Так вот у разных приложений есть разные способы оповещения. У многих их просто нет (например как у большинства X приложений).

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

Здесь жконф позволяет сделать просто огромный шаг вперёд.

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

2. Все приложения использующие жконф могут использовать стандартный механизм оповещения, который будет их оповещать только об изменившихся параметрах. Жконф предоставляет готовую стандартную библиотеку, которая содержит необходимый API для языка C.

3. Встроенные механизмы проверки позволяют проверить соответствие изменяемых параметров необходимым ограничениям. То есть ситуация, когда пользователь сделал ошибку при редактировании параметра будет исключена. До тех пор конечно, пока он не захочет воспользоваться старым методом и запустить vim чтобы подрихтовать что-то вручную.

4. При всём при этом, остаётся возможность выбора бакэнда(формата) и возможность сетевого взаимодействия, без необходимости что-либо специально для этого программировать или изменять в приложении.

[snip]
--
Best regards, Sergey Spiridonov




Reply to: