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