Re: gconf2 на сервере
On 2003.07.02 at 03:07:16 +0200, Sergey V. Spiridonov wrote:
>
> Один аргумент: не всегда такая схема оптимальна. Например когда я хочу
> использовать ЦПУ память винт клиента, распределить нагрузку, разгрузить
> сеть.
Это почти не аргумент. Если ты строишь информационную систему с нуля,
то ты просто не будешь тратить деньги на CPU/винты на каждое рабочее
место.
Ситуации, когда такая схема неоптимальна, бывают, но ты не там их ищешь.
> Другой: если у меня иерархия серверов, и часть настроек хранится на
> более высоком уровне (например сервер предприятия - сервер отдела), всё
> равно нужна синхронизация.
Перестань мыслить в категориях клиент/сервер и тебе станет гораздо
лучше.
>
> То?
Все это g выбросить нафиг, и искать решения в другой области - NIS+,
LDAP, rsync, rdist.
> Некоторые сложные в настройке приложения действительно используют свой,
> иногда очень сложный язык. Некоторые берут уже существующий язык и
> используют его для настройки. Я не буду на них останавливаться, так как
> для каждого нужен свой отдельный подход, да не так уж их и много.
А в остальных случаях все вполне укладывается в концепцию иерархической
базы данных с наследованием, т.е. xrdb.
> >Не спорю, хороший текстовый редактор написать сложно. Но они уже
> >написаны. Целых два.
>
> Прокрустово ложе текстовых редакторов? Жконф позволяет использовать всю
В текстовом формате можно представить все, вплоть до растровой графики.
> мощь целых двух текстовых редакторов: сторонники emacs могут
> использовать его для редактирования настроек. Но также жконф упрощает
> написание специальных утилит для администрирования.
>
Я все-таки в упор не понимаю смысла "специальных утилит для
администрирования". Если некоторые настройки меняются часто, то это не
администрирование, а такая разновидность использования приложения. И
управление этими настройками должно быть интегрировано в само
приложение.
Если же настройки меняются редко, то писание интерфейса не окупается.
Reply to: