MCS design proposal

[Stephan Arts]

On 7/9/07, Jannis Pohlmann <jannis at xfce.org> wrote:
> Am Sun, 8 Jul 2007 22:13:49 -0700
> schrieb "Brian J. Tarricone" <bjt23 at cornell.edu>:
>
> > 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.
>
> Yep, I also think that a method like this would suffice.
>
> > On a side note, can we *please* not call the new system MCS?  Just
> > make up a new name.  It's confusing as-is.
>
> I'm not good at finding names for programs and libraries, but I agree
> with you. We could as well renaming "channels" to "domains" or
> "packages" (though this might be a little too Java) or something else.
> Suggestions, please!

As a follow-up on libfrap, could we do something with coffee again?! :p

>
>   - Jannis

Stephan