MCS design proposal

[Stephan Arts]

On 3/20/07, Jannis Pohlmann <jannis at xfce.org> wrote:
> Hey all,
>
> I have uploaded my thoughts about a new MCS design to
>
>   http://lunar-linux.org/~jannis/mcs-design-proposal.txt
>
> This topic has been on our list for quite some time but we never made
> it to a design draft. So here are my ideas. Hopefully they will be
> start of a productive discussion - I hereby encourage anyone to
> participate in it.
> I'll keep the .txt updated with relevant opinions. Here's the initial
> document:
>
> Xfce MCS Design Proposal
> ========================================================================
>
> The MCS daemon is a process running in the background. It manages all
> settings inside a root path (like $XDG_CONFIG_DIRS/xfce4/). The settings
> could be stored in many different ways, e.g.
>
>   * one big XML file (not recommended, unflexible)
>
>   * several XML files in subdirectories, e.g.
>
>       $XDG_CONFIG_DIRS/xfce4/core/panel.xml
>       $XDG_CONFIG_DIRS/xfce4/core/desktop.xml
>       $XDG_CONFIG_DIRS/xfce4/applications/application-browser.xml
>       $XDG_CONFIG_DIRS/xfce4/extensions/thunar-media-tags.xml
>
>   * .desktop files in subdirectories, e.g.
>
>       $XDG_CONFIG_DIRS/xfce4/core/panel.desktop
>       $XDG_CONFIG_DIRS/xfce4/core/desktop.desktop
>       ...
>
> Personally, I prefer the second solution as XML files give us the
> possiblity to create property hierarchies.
>
> In the MCS concept, applications and libraries are not able to read or
> write settings on their own. They have to query the MCS daemon for this.
> Using D-Bus, we could define the following interface:
>
>   <interface name="org.xfce.MCS">
>     <method name="Set">
>       <arg name="channel" type="s" direction="in"/>
>       <arg name="property" type="s" direction="in"/>
>       <arg name="value" type="v" direction="in"/>
>     </method>
>     <method name="Get">
>       <arg name="channel" type="s" direction="in"/>
>       <arg name="property" type="s" direction="in"/>
>       <arg name="value" type="v" direction="out"/>
>     </method>
>     <signal name="Changed">
>       <arg name="channel" type="s"/>
>       <arg name="property" type="s"/>
>       <arg name="value" type="v"/>
>     </signal>
>   </interface>
>
> In this interface, all clients can query the MCS for settings based
> on a channel (or domain, e.g. "xfwm4") and a property name (e.g.
> "focus/follows-mouse"). The value parameter is a GValue ('v' stands for
> variant) which makes handling different value types (string, int,
> float, boolean etc.) pretty easy.
>
> The MCS daemon should probably also listen to XSETTINGS events. I have
> no experiences with XSETTINGS, so I'm not exactly sure how this would
> work though.
>
> MCS clients may connect to the "Changed" signal of the org.xfce.MCS
> interface in order to be informed of property changes. Properties may
> change if a) some other client sets them or b) the properties file
> changes.
>
> Due to b) the MCS daemon also has to monitor all files for changes,
> e.g. using FAM/Gamin.

I was just wondering, what is the status of this discussion (and the spec)?

Regards,
Stephan