MCS design proposal

[Stephan Arts]

On 7/7/07, Bo Lorentsen <bl at lue.dk> wrote:
> 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 :-)
>
> > 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 :-))
>
> > 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 ?
>
> I don't understand the plugin part, what is it that can be plugged in ?
>
> 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.

That is the general idea of the mcs-manager using dbus, since dbus is
a general interface *anything* can be used to store the data. (IIRC)

Regards,
Stephan