周五的 mailteam 技术例会上，说起运营监控系统的配置，当时我提出直接写脚本来配置就好了，但遭到了一堆人的反对，指出现在使用的 XML 工作的很好...
会上并没有就这个问题深入讨论，会后就想着就这个问题写一篇 blog，正好看到沈崴也刚刚写了一篇文章阐述类似的问题，不过他介绍的是如何用 py 进行配置的实作，非常有价值。
我没有他那样的实际经验，只是以前在和 zhb 的一系列讨论后隐隐约约总结出 script 比 config 有莫大的好处：
1. 机器的可读性。script 引擎本身就是一个天然的配置分析程序，这点上和 XML 打个平手。
2. 人类的可读性。这个比 XML 强太多
3. 可配置性。这个也比 XML 强太多，或者说实现起来比 XML 自然的多
会议上提到的脚本配置的缺点是如果脚本写错了会影响程序执行，其实并不是理由，因为 python 是可以动态 import 的，对导入配置的异常做额外处理就好了，事实上任何系统配置都免不了要做这个。
另外一个很容易被想到的缺点就是 XML 配置文件可以应用于各种语言写就的程序，而 py 脚本貌似只能在 python 里面使用。实际上 py 脚本（或者说 python 对象）是可以在 C/C++ 里面访问的，现在网游客户端包括 QQ 不都是这么做的么。
在我看来，问题真正的核心在于配置文件编写人员，或者说习惯于在 web 上提交表单的管理员们，是否愿意去学习一门新的脚本语言
记得一个超有名的黑客说他教文职秘书们配置 emacs，她们没有人意识到实际上是在写 lisp 程序。 :)
Topic:
本站的feed
评论
有一点疑问
不管是用lex+yacc还是使用SHELL或者Python脚本来充当的配置文件，我觉得对比XML的配置文件的缺点就是可读性虽然强，但是机器写起来差一些。
晚辈见过一些使用XML做配置文件的程序，配置文件很少许要用户编辑，而是都是通过图形界面的配置程序生成的。比如GAIM的配置。改动不但直接的生效，而且会同步到磁盘的XML配置文件上。这样的配置文件不论是程序和人来维护都非常方便（查看、编辑也主要是为了排错）。
另外，虽然也可以通过附带或者内置的工具生成脚本。比如说众多Linux发布版本采用的配置方式，由图形界面配置生成一些系统配置文件。比如说/etc/resolv.conf但是手工改动这个文件不会在图形配置工具上反应出来。图形配置工具保存设置的地方应该在/etc/sysconfig/network中。这样对于CLI/GUI的交叉维护似乎会造成一些不扁。尤其要保留随意的原有顺序和注释都更加困难。
所以，晚辈觉得:
1、仅仅通过GUI设置，BIN的即可；
2、大部分时间GUI设置，小部分情况CLI编辑,XML是首选；
3、大部分时间GLI管理，GUI占小部分时间或者只作向导生成，常规配置文件/脚本。
不太成熟，希望您别见笑。
补充一下笔误，前面
补充一下笔误，前面指用lex+yacc解析配置文件。：P
其实配置文件如何用
其实配置文件如何用确实是首先看用户的需求，就我现在考虑的方向，脚本应该是一个不错的选择。
至于你提到的 CLI/GUI 交叉维护的确是一个值得思考的方面。显然 LSB 和各个 Linux 发行版试图同时吸引黑客和一般性使用者，反而可能导致同时得罪双方。归根结底还是用户定位的问题。
类似的讨论还包括 JSON vs XML，细究起来也是分场合
觉得xml更容易生成我
觉得xml更容易生成我觉得完全是偏见，现在这么多方便的模版语言，生成什么都很容易。
脚本可能偏好是老系
脚本可能偏好是老系统管理员
xml的页面提交方便新人，hoho
强烈支持你的观点，
强烈支持你的观点，我们这现在都是用python写杂碎程序，所以配置基本上都是Python语言，用的很方便.
如果用脚本做config的
如果用脚本做config的话，lisp是无敌的了(牛了20年的emacs)。
解析和反向生成都不需要额外的转换：数据就是代码，代码就是数据。
我觉得这个主要是个
我觉得这个主要是个习惯问题，会上被反驳的原因主要是使用习惯和学习门槛（真实存在的门槛和心理上的可能不相符），以及对脚本的接受程度；另外还有改变现有模式，也要花不少时间。其实真的搞个新的东西出来使用脚本配置的，也不会有人有什么意见。
我觉得很多时候判断的标准，并不是客观的技术实现的事情，还有一个很重要的因素是人。就好像软件或网站设计中的 UI 设计，得让用户能容易接受。
回过头来说会上讨论的那个配置文件，程序本身是 perl 的。。。