On Wed, 21 Mar 2007 20:53:17 +0000 Richard Hughes <[EMAIL PROTECTED]> babbled:
> On Wed, 2007-03-21 at 21:19 +0100, Oswald Buddenhagen wrote: > > On Wed, Mar 21, 2007 at 07:26:43PM +0000, Richard Hughes wrote: > > > On Wed, 2007-03-21 at 20:02 +0100, Oswald Buddenhagen wrote: > > > > that's not the point. i was talking about privilege elevation through a > > > > password dialog and similar. > > > > > > That's not the job of a session power management interface. You're not > > > going to present to the user: > > > > > > ===== Suspend ====== > > > You have not got the permissions to suspend > > > Enter root password: [_______________] > > > > > actually, i *am* going to. the login managers (can) do the same for > > complete shutdown, so there is no reason not to do so for "partial" > > shutdown (which also suspends network services, etc.). > > No offense intended, but I think this is really crazy. agreed. the admin (or distribution setup) should set the policy - can normal users at the console shutdown, reboot, suspend etc. for "desktop distros" this will likely be turned on by default. i see no point in exposing the need to enter authentication to do such a basic thing that the vast majority of users will simply EXPECT to be able to do with THEIR desktop. as below - they can just yank the power cord and cause much more damage instead. > > > Either the user can suspend or not. > > > > > quite simplicistic world view. :) > > Well, yes. I can't think of a single use case where we would want to > raise a privilege to do something like shutdown. If a user has physical > access to a machine they can just pull the power cord. > > > > > generalizing it, a simple "may/may not" answer might be > > > > insufficient, as the user might be able to change the situation. > > > > > > How? Got any real-world use-cases? > > > > > ask the thin client user at the next desk to log out from this box. > > wait for a download to complete (okay, we miss quite a lot of > > infrastructure to actually detect such a situation). > > cancel/reschedule the cron job in ten minutes. > > i can go on forever ... > > Err, real world power management use cases? Can you elaborate on these a > little please. > > > > Sorry I don't understand - are you saying that we shouldn't split the > > > session and system stuff? If so, all the UI will have to abstract all > > > the hardware again, and we are back to abstracting HAL in each > > > application with no gain. > > > > > i guess this is not what i'm saying, as i really have no idea what you > > are talking about. :} > > a policy brings together event sources, matches them against conditions > > and triggers actions. from may 2006 mail it should become clear that > > both the events and actions can be of very different kind, but still be > > subject to one policy. this also means one user interface, unless you > > want to make it completely incomprehensible (like the current dmps vs > > screensaver situation in kde). splitting the api by actions but still > > providing policy functions in them (fooAllowed) is just odd in that > > context, as all clients and all servers of these apis are the same two > > programs. > > Err. We just need a simple API for stuff like beagle to ask "is this > laptop on AC power" so it can avoid burning the disk on battery power. > It's not about policy control, that's up to the dameon which will vary > between implementations. > > > > We need the session interface to present stuff that is trivial for > > > applications to process. Anything more, and they can query HAL > > > directly and do their own logic. > > > > > that makes your "standard" redundand, because a fully-fledged > > implementation would always opt for the latter (even if it would offer a > > simple frontend by default). > > No. Beagle shouldn't have to worry that we have a UPS attached, and two > batteries, which discharge sequentially, just to make a *trivial* policy > decision. > > Richard. > > > _______________________________________________ > xdg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
