MCS design proposal

[Brian J. Tarricone]

On Sun, 8 Jul 2007 13:58:44 -0400 Erik Harrison wrote:

> On 7/8/07, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
> > On Sun, 8 Jul 2007 13:07:20 -0400 Erik Harrison wrote:

> > > 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.

Well, we could potentially do it that way, but we don't.  AFAIR, all
the Xfce modules that use kiosk mode check XfceKiosk in the
application.  In that case they usually ignore MCS entirely and rely on
hard-coded defaults.

> 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.

Not necessarily.  A simple org.xfce.MCS.SettingIsWritable() method
seems pretty straightforward.  The daemon should be smart enough to
return the proper locked-down values based on the uid of the process
connecting to it.

On a side note, can we *please* not call the new system MCS?  Just make
up a new name.  It's confusing as-is.

	-brian