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.

Nice design :)

I am curious though, why would we port the mcs-api into dbus?
I was thinking for something in the likes of this:

<interface org.xfce.settings.panel>
   <!-- stuff ( i don't have the settings available to me right now ) -->
</interface>
<interface org.xfce.settings.xfwm4>
   <!-- stuff -->
</interface>
<!-- other interfaces -->
<interface org.xfce.settings.keyboard>
   <!-- stuff -->
</interface>

I don't know that much about D-Bus yet, so this might be a terrible
idea, tell me.

Regards,

Stephan