org.freedesktop.PowerManagement

[Oswald Buddenhagen]

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

> Either the user can suspend or not.
> 
quite simplicistic world view. :)

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

> > then don't make it complicated. provide a series of hooks (through
> > attribute lists and similar) that allow communicating with a policy
> > framework.
> 
> Such as? It's easy to say, but putting into a generic interface is
> very difficult.
>
well, i figure. maybe a list of variants to start with. i haven't
thought about this, yet.

> > > I also think it's quite important to keep the difference between a
> > > screensaver with idle detection, console detection, and power
> > > management user interaction for the sake of defining an API.
> > > 
> > i'm not that sure, obviously. they all meet at the mechanism to
> > implement a policy. it seems silly to me to have a common policy
> > framework in the deamons implementing the various power-related
> > functions and on the client side glue code that brings together the
> > policies of the separate apis again (it has to be presented to the user
> > in a coherent way).
> 
> 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.

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

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.