MCS design proposal

[Jannis Pohlmann]

Am Sun, 8 Jul 2007 13:58:44 -0400
schrieb "Erik Harrison" <erikharrison at gmail.com>:

> On 7/8/07, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
> > On Sun, 8 Jul 2007 13:07:20 -0400 Erik Harrison wrote:
> >
> > > I don't really speak current MCS, so maybe I'm being stupid. But
> > > unless we specify ways to alter the daemon's behavior, then why
> > > do we need an IPC interface to the same ol' config files?
> >
> > The current MCS daemon behavior sucks.  It's the only process
> > allowed to *set* config values, and no other clients connecting to
> > it are allowed to do so.
> >
> > > The advantage of
> > > MCS to me is being able to plugin something like a kiosk mode,
> >
> > No, the current MCS daemon has nothing to do with kiosk mode.  Kiosk
> > mode is implemented (poorly, in many cases) in each individual
> > application.  It's totally settings-manager-unaware.
> 
> Allow me to restate - the value of the MCS *design* if not the
> implementation is being able to control access to gets/sets without
> putting in application specific code.

Yes. It provides a simple interface for reading/writing settings which
all programs can use. Applications no longer need to worry about file
locations and config file formats. They only call the get- and setters
and the MCS daemon performs the actual read/write operations.

There's even more the daemon can do: it may handle the kiosk mode, it
may have plug-able storage backends, it may send property
change notifications to channel listeners etc.

> Upon further reflection though, I'm not sure that Jannis's outline
> really gives us enough for even that, because to do this properly, one
> would need to be able to query MCS for what it's allowed to set and
> what it isn't, which potentially complicates the API considerably.

Well, we could add a function like

  gboolean xfce_mcs_channel_is_readonly (XfceMcsChannel *channel, 
                                         const gchar    *property)

to the XfceMcsChannel class. Using this function client applications
would be able to grey-out or hide controls for read-only properties.

We could also add a GError** parameter to all set_* functions in order
to catch errors like when trying to set protected properties or when
the MCS daemon is not running.

> >
> > > or have
> > > the daemon figure out where I want to store my data if I'm
> > > running an application remotely.
> >
> > Yeah, this is one of the nice things about current MCS, but really,
> > all it's doing is abusing XSETTINGS for this, and I don't think it's
> > totally necessary to have network transparency for settings as well.
> >
> > > I really think that all of the stuff about opening a settings
> > > dialog should go away. The MCS application as anything special
> > > should go away. An app can open it's own dialog, and if you
> > > install a .desktop file, then so can anything else. I'd like to
> > > see the xfce-settings-show style app that simply
> > > aggregated .desktop files in the Settings category. Then the
> > > Settings menu in the desktop menu can go away, as it's a
> > > violation of all things holy.
> >
> > Yeah, I agree.  This also lowers the barrier to writing another
> > implementation of the spec.  The part that knows about parsing
> > special .desktop files to deal with settings panels can (in Xfce's
> > case) run in the same process as the settings daemon proper, or not.
> > Let's leave the UI out of the settings manager proper.  (Though we'd
> > need a separate, likely Xfce-specific spec for how to handle the
> > settings panels.)

I also agree. The settings dialog could be a simple program for
loading, displaying and launching the "plugins". No need to put this
into the MCS code.

  - 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/bd36382c/attachment.pgp>