Re: gconf2 на сервере
Oleg Gritsinevich wrote:
Конечно же нет. Меня интересует (хотя я уже догадываюсь) в какой
позе будут находиться приложения на хостах, пользующиеся gconf-ом по
сети, в случае проблем с сетью/самим конфигурационным сервером.
1. Проблемы с сетью (как сделано это сейчас): в зависимости от настроек
локального хоста либо поднимается локальный жконф, использующий
локальные настройки, либо
2. Жконф недоступен - в зависимости от области применения приложения оно
продорлжает работу без жконф (если это имеет смысл), либо прекращает работу.
Ещё меня очень интересуют вопросы бэкапа и восстановления
конфигов, переноса конфигов между машинами.
Здесь всё пока по старому - tar, scp, dump/restore... Хотя не исключаю
появления утилит специально заточенных под жконф.
[skip]
Если есть возможность улучшить проверку, то зачем от неё отказываться?
Мы всё ещё говорим о семантической проверке? Тогда приведите,
пожалуйста, пример как можно улучшить семантическую проверку конфига
iptables в общем случае.
Я говорил о случае зависимых параметров, когда параметр А ограничивается
условием зависящим от параметра Б. Это семантика? Если нет, тогда я
говорю не об этом. Семантические (смысловые) ошибки в Вашем примере
может отловить только пользователь, но при чём тут жконф или /етц, етц
тоже ведь не помогает ловить такие ошибки?
Возможность дополнительной проверки на стороне сервера это
Я очень надеюсь на то, что возможность использования gconf и в
дальнейшем останется всего лишь возможностью.
Я тоже считаю что всегда должен быть выбор, зачем ограничиваться?
Давно уже появились и хранение аккаунтов в маэскуэль и в лдап, я думаю
что рано или поздно мы придём к чему-то подобному жконф. Хотелось бы
однако, чтобы переход не был столь мучительно долгим и болезненным, как
например, с юникодом.
--
Best regards, Sergey Spiridonov
Reply to: