MCS design proposal

[Erik Harrison]

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.

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.

>
> > 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.)
>
>         -brian
>
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/xfce4-dev
>


-- 
Erik
"If you want to go somewhere, goto is the best way to get there." - Ken Thompson