MCS design proposal

[Jannis Pohlmann]

Am Sat, 07 Jul 2007 19:11:58 +0200
schrieb Bo Lorentsen <bl at lue.dk>:

> Jannis Pohlmann wrote:
> 
> > Well, it's mainly an overhauled version of the current design. It
> > uses D-Bus and thus is not bound to the X server. The whole design
> > is more "GOO" (GObject orientated). To give an example: instead of
> > passing callback function pointers to the MCSClient you would just
> > connect to the "property-changed" signal of the channels.
> Ok, that sounds nice, and a bit GConf like :-)

GConf has additional features like "schemas" which are used in
gconf-editor to display localized information about each property to
the user. IMHO that's not really necessary as users should not have to
deal with editing properties manually anyway.

> > So it's basically all about using more modern concepts (D-Bus,
> > more GObject) and therewith preparing the MCS part of Xfce for the
> > future.
> Ok, sounds like some worthy goals (need to read up on d-bus I
> guess :-))

As Stephan said, D-Bus is a system which allows to define
certain interfaces which are then being used for processes to
communicate with each other. Once you have such an interface, you can
easily switch between different applications implementing the same
interface. 

> > Whether to get involved in GConf or not has not really been
> > discussed there though. I know that Benny is all for it while I am
> > not. Others have not raised their voice on this topic yet AFAIK.
> What is the advantages of this MCS model in relation to GConf except
> for the d-bus part ?

There's only minor differences here. GConf currently uses ORBit for IPC
but it's very likely that they will switch to D-BUS in future versions.

The easiest way to explain the MCS model is this: Imagine all
properties are identified by an URI. AFAIK, GConf uses absolute URIs
for all properties while the MCS model makes it possible to define a
base URI (a "channel") which is then used for all property queries.

The MCS concept makes it possible to apply restrictions (e.g. in kiosk 
mode) to certain channels. 

> I don't understand the plugin part, what is it that can be plugged
> in ?

In Xfce these "plugins" are the configuration dialogs displayed in the
settings manager. That's it. We could of course move them out of the
MCS manager and create a separate configuration program which only
manages these plugins and is able to display the main config dialog as
well as launching the plugin dialogs.

> And, could it not be possible to have more than one storage mechanism 
> for then need MCS, like Debconf ? In that way we could store things
> in XML, misc DB or an LDAB server, depending on what we what to
> achieve.

Of course that is possible. You could write a replacement for the Xfce 
MCS manager which implements the org.xfce.MCS D-BUS interface. We could
also implement a kind of backend plugin system for different storage
mechanisms. The design is flexible enough to implement that later
without much refactoring.

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20070708/01bd4c0c/attachment.pgp>