关于Gconf改造的构想
转载时请注明出处：http://blog.csdn.net/absurd
开源社区真是个百宝园，什么好东西都有。可以免费用(当然要遵守相应的规则)不说，而且都带有源代码，用得不顺手时还可以修改它。那Gconf来说吧，Gconf和gnome-vfs可以说是GNOME桌面环境的两大亮点。至于后者我们暂时不考虑了，这里说说gconf的功能，以及改造它的原因和方式。
一般介绍Gconf时都会说，它的功能相当于Win32下的注册表，但功能更强大，使用更方便。这话其实也不完全正确，前半部分是对的，功能确实和Win32下的注册表差不多。说它功能更强大，我想可能是指设置变化自动通知机制吧，即设置改变后，会通知相关应用程序，应用程序此时会根据设置改变自己的行为/外观。应用程序不需要不断查询设置是否改变了，这由传统的轮询(poll)方式变成中断方式，向前迈进了一大步。其实现在Win32下的注册表已经支持变化通知机制了，sysinternals 根据这个原理实现了一个注册表监控工具。我不清楚具体的实现，反正至少是有了这个机制。
关于使用更方便这一点也是真的。如果单纯的从调用接口函数来看，gconf的优势不大，因为注册表的调用接口函数也很简单。但从配置管理来看，gconf的优点就显现出来了：首先，它采用XML格式的文本文件作为载体，不用任何工具可以直接编辑它，而不像注册表使用一个二进制文件，只有通过regedit才能编辑它。其次，Gconf采用多级目录存放配置文件，备份部分配置信息，或者删除无用的配置信息都非常方便，而不像Win32下采用单一注册表文件，这个文件变得越来越大，垃圾越来越多，想对它进行瘦身处理可不是件容易的事。另外，Gconf的配置信息还带自描述的schema，每项配置信息的功能、格式和类型都一目了然，这让配置管理更加容易。
Gconf对GNOME桌面环境的整合是贡献巨大的，它让各个应用程序协同工作，它们之间的耦合是非常松散的。Gconf采用了MVC模式，这是解耦的最佳方式之一，不过这里与传统的MVC模型还是有点差别，这个系统由多个应用程序组成，应用程序可以看作是视图，而作为daemon运行的gconfd可以看作是model，它负责配置信息的管理和事件通知。
Gconf在GTK+应用程序中的应用越来越广泛，在我们的系统中支持gconf无疑是明智的选择。但问题在于Gconf采用的CORBA作为进程通信机制，这让人有些不爽，在手持设备中使用CORBA有些大材小用。我们已经选择用DBUS作为进程间通信机制了，再加CORBA也是很浪费的。所以我们决定用DBUS替换gconf中CORBA。
研究了一下gconf的代码，对它的架构有了基本的了解。它主要由四部分组成：
1. 服务器端。服务器主要负责接收客户端的请求，然后调用后端(backend)存取配置信息。服务器作为一个daemon运行，只有一个实例，对所有请求串行化，避免对配置文件访问冲突。
2. 客户端。客户端提供一套简单易用的接口。你可以选择本地(local)方式，在这种方式下，客户端与后端(backend)打交道，直接操作配置信息文件，所有动作都在一个进程中运行。也可以选择远程方式，它把请求通过CORBA发送给服务器，由服务器执行并返回结果。
3. 后端。后端直接操作配置文件，负责文件的读取、写入和缓冲处理。后端可以有多种不同的实现，但都遵循统一的接口，根据参数选择不同实现的后端。
4. 公共函数库。一些公共的代码，像错误处理、字符集处理和listener等等。
Gconf对于进程间通信的代码隔离得不太好，这些代码分布相当广。为了替换进程通信机制，几乎要重写客户端和服务器端绝大部分代码。要把CORBA替换成DBUS不是那么容易的事，以前有人做过类似的尝试，似乎都失败了。
客户端和服务器端代码本身比较复杂，要抽取进程间通信的代码比较困难，所以我决定干脆完全摒弃这部分代码，只是保留客户端接口，以便兼容应用程序，同时利用gconf的后端，省去对文件操作的工作。现在对DBUS的使用已经得心应手，做这样的改造好像并不难，但为了慎重起见，还是再花几天时间研究一下。
~~~end~~