Conception of gconf Transformation

Conception of gconf Transformation

 

Please indicate the source when reprint: http://blog.csdn.net/absurd

 

The open-source community is really a treasure garden, and there are everything. You can use it for free (of course, you must follow the relevant Rules) without saying it, and it carries the source code. You can also modify it when it is not easy to use. For gconf, gconf and gnome-VFS are two highlights of the GNOME desktop environment. For the latter, we will not consider it for the moment. Here we will talk about the gconf function and the reasons and methods for transforming it.

 

Generally, gconf is described as a function equivalent to the Win32 registry, but it is more powerful and easy to use. This is actually not completely correct. The first half is correct, and the function is indeed similar to the Registry under Win32. It is more powerful. I think it may be about setting the automatic notification mechanism for changes, that is, the relevant applications will be notified after the settings are changed, the application changes its behavior/appearance according to the settings. The application does not need to constantly check whether the settings have changed. This changes from the traditional polling (poll) method to the interruption mode, making it a huge step forward. In fact, the Win32 Registry now supports the change notification mechanism. sysinternals implements a registry monitoring tool based on this principle. I don't know the specific implementation. At least this mechanism is available.

 

This is true for ease of use. From the interface function call alone, gconf has little advantage, because the Registry's interface function call is also very simple. However, from the perspective of configuration management, the advantages of gconf are apparent: First, it uses text files in XML format as the carrier and can be edited directly without any tools, unlike a registry that uses a binary file, it can be edited only through Regedit. Second, gconf uses multi-level directories to store configuration files, back up some configuration information, or delete useless configuration information. Unlike Win32's use of a single registry file, gconf becomes larger and larger, as there is more and more garbage, it is not easy to slim it down. In addition, gconf configuration information also includes a self-described schema. The functions, formats, and types of each configuration information are clear at a glance, which makes configuration management easier.

 

Gconf makes great contributions to the integration of GNOME desktop environments. It allows various applications to work collaboratively and the coupling between them is very loose. Gconf adopts the MVC mode, which is one of the best decoupling methods, but it is a little different from the traditional MVC model. This system is composed of multiple applications and applications can be seen as views, gconfd running as daemon can be considered as a model, which is responsible for managing Configuration Information and Event Notifications.

 

Gconf is widely used in GTK + applications. It is undoubtedly a wise choice to support gconf in our system. However, the problem lies in the fact that gconf uses CORBA as a process communication mechanism, which is a bit unpleasant. It is a little useless to use it in handheld devices. We have already chosen to use middleware as the inter-process communication mechanism, which is also a waste of adding a piece of CORBA. Therefore, we decided to replace CORBA in gconf with promise.

 

I have studied the gconf code and have a basic understanding of its architecture. It consists of four parts:

1. server side. The server is mainly responsible for receiving client requests and then calling backend to access configuration information. The server runs as a daemon and has only one instance, serializing all requests to avoid access conflicts to the configuration file.

 

2. Client. The client provides a set of easy-to-use interfaces. You can select the local mode. In this mode, the client deals with backend and directly operates the configuration information file. All actions are executed in a process. You can also select the remote method, which sends the request to the server through CORBA, and the server executes the request and returns the result.

 

3. backend. The backend directly operates the configuration file to read, write, and buffer the file. The backend can be implemented in a variety of ways, but all follow the same interface and select different backend implementations based on parameters.

 

4. Public function library. Some common code, such as error processing, Character Set processing, and listener.

 

Gconf is not well isolated from codes for inter-process communication. These codes are widely distributed. To replace the process communication mechanism, the vast majority of code on the client and server needs to be rewritten. It is not that easy to replace CORBA with a promise. It seems that some people have tried this in the past and all of them have failed.

 

The client and server code are complicated and it is difficult to extract codes for inter-process communication. Therefore, I decided to discard the code completely, but to keep the client interface to be compatible with the application, at the same time, gconf backend is used to save the effort for file operations. The use of compaction is now handy, and it does not seem difficult to make such a transformation. However, to be cautious, it may take a few days to study it.

 

~~~ End ~~