The reasons why an existing configuration mechanism, and in particular, the Xrm database, was not used is discussed above. Various other design decisions are discussed below:

Why aren't the contents of the property stored in XML?  The data format is designed to be space efficient and to be easily and efficiently parsed with minimal code. These are not things XML does well. Flexibility of structure, things that XML does well are not needed here. If needed, XML can be used for the contents of individual settings.

Why is the settings property screen specific?  While most settings are expected to be shared across all screens of a display, some settings, such as font sizes will be screen specific, and it is considered easier to let the settings manager propagate shared resources across screens then to have both screen-specific and screen-independent resources.

Why does there need to be a "settings manager" process running?  Having a process always present as the owner of the _XSETTING selection ensures that there are no race conditions and is simpler than trying to create a locking mechanism that can work without a persistant process. It is also expected that to properly handle notification of changes to the stored properties most desktops will want a process running to watch for changes in any case. In cases of tight resource usage, the settings manager can be combined with some other function, such as the window manager or session manager.

Why use a single property for all settings?  Using a single property has several advantages. First, retrieving all settings takes only a single round-trip to the server instead of a round-trip for each settings. Second, it means that when multiple settings can be changed at once, only a single notification is received by clients, and clients will see interrelated properties changed in an atomic fashion.

Why is the _XSETTINGS_SETTINGS property stored in the endianess of the manager instead of a neutral endianness?  This conforms to the way many other X mechanisms work. The main reason for doing it this way is to save conversions for the common case when the client and manager are on machines of the same endianness.

When the settings manager exits, why should clients reset the values to the default settings instead of keeping the current settings?  Resetting the settings to the default values is preferred to maintaining the current values because it makes sure that all programs on the desktop have consistent values for settings whether they were started before or after the settings manager exited. It is not expected that changes in the current settings manager will occur very often.