DeviceKit-power and latency control

[David Zeuthen]

On Tue, 2008-11-11 at 12:08 +0000, Richard Hughes wrote:
> > Why wouldn't the admin just use the same method? I'm not sure why we
> > need two separate methods. I mean, with a CancelLatencyRequest() and
> > proper user interface the admin can just remove requests that way.
> 
> Nahh, the admin interface is "sticky" i.e. the admin can issue the
> request, disconnect and the the setting is persistent across reboots and
> sessions. The user request gets cleaned up on disconnect.

It sounds somewhat useful that the admin can define such "sticky"
requests.

Maybe the proposed GetLatencyRequests() method should return a boolean
for every request whether it's sticky or not? 

Because then (with appropriate privilege) CancelLatencyRequest() can be
used to remove it. So this means CancelLatencyRequest() will need a
different PolicyKit authorization depending on the value of the cookie.

So the sticky requests would need some sort of cookie too.

So that begs the question, why would we have two methods

 RequestLatencyGuarantee()
 RequestStickyLatencyGuarantee()

why not just a single one

 RequestLatencyGuarantee(string type, int value, bool is_sticky)

requiring different polkit authorization depending on whether
is_sticky==TRUE.

> > > > 7. GetLatency() is probably the right name since it will be computed
> > > > from the set of outstanding requests. What does it return if there are
> > > > no outstanding requests?
> > > 
> > > I guess -1, although that needs to be in the docs.
> > 
> > Isn't there a default latency we can read from somewhere? If possible, I
> > definitely think we want to return something meaningful instead of e.g.
> > -1 meaning "not set".
> 
> The (yet to be written) config file, /etc/DeviceKit-power/defaults.conf

So one of the things I really want to achieve with the DeviceKit stuff
is a clean separation between interface and implementation so it's easy
to write another implementation (including e.g. having all DeviceKit
daemons run in the same process). 

This is not so much because I expect people will reimplement these
services (our reference implementation should be good enough that people
won't need to), more so we have the freedom to change things later on.

As discussed on IRC, I'm going to commit a few changes to make that
easier to achieve, the main one being moving the objects around e.g. /
-> /org/freedesktop/DeviceKit/Power and so forth. This probably means a
small change in gnome-power-manager's devkit-power branch but I think
it's pretty much worth the change.

Anyway, when it comes to configuration files (once we get around to add
this) we need to diligently point out that such a file is just an
implementation detail and that it might go away / change format / change
location. This is actually not far fetched; since this is a
configuration value you really want something like GConf's stacking to
store it, e.g.

 o system-mandatory
 o site-mandatory
 o org-mandatory
 o factory-mandatory
   (normally you'd have per-user here but this is a system daemon)
 o system-defaults
 o site-defaults
 o org-defaults
 o factory-defaults

and things like reading this stuff from e.g. a LDAP directory service
instead of local files. Or however an abstraction for
Settings/Preferences read/write from.

Of course it's not reasonable to use GConf from a system daemon but one
of these days we'll have things like GSettings/DConf in the glib stack
where it's suitable for system daemons. And then we want to change our
implementation to use that. Then, in some star trek universe many light
years away, the admin might change all the latency requests for the
whole site or organization.

In particular we need to say that the D-Bus interface should be used to
change these values, editing the config file will never reliably work.

> > I mean, with the system running and all, I think
> > there is *some* default latency set even when no application has asked
> > for it...
> 
> Right. Thanks again for the review.

No problemo. Can you upload the new interface when we've got the changes
in? Since it's public API and all, another round of review might be
good.

     David