org.freedesktop.PowerManagement

[Richard Hughes]

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.

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