org.freedesktop.PowerManagement

[Rob Taylor]

Richard Hughes wrote:
> On Wed, 2007-03-21 at 15:58 -0400, Havoc Pennington wrote:
>> Though dbus does allow you to do these async (fire them all off then 
>> wait for all results), which I would recommend for anything an app is 
>> doing at startup, even though it's sort of painful. Assuming most
>> apps 
>> will be doing a variety of calls on startup it probably will speed up 
>> app launch if say 20-30 round trips are all done async instead of
>> with 
>> blocking round trips in serial.
> 
> Sure, agree.

Umm, i was actually talking about context switches, nothing to do with
async versus sync. I'd expect an app to do async calls on startup.
I guess its theoretically possible at the libdbus level to queue up a
number of messages and do one context switch to send them all...

The main reason I bring this up is from an ARM point of view. As context
switches are relatively costly on ARM, it makes a lot of sense to design
 your api with number of context switches for common/startup operations
in mind.

>> As an alternative to a bitfield, one option is a dictionary of 
>> properties. This is most likely nicer than a bitfield in say python,
>> and more annoying than a bitfield in C.
> 
> Yes, a dictionary might be nice, but it's not trivial to access in C.
> This stuff really needs to be *trivial* for an application to access,
> hence why I think booleans are probably best.
>

*shrug* In Telepathy we used bitfields and there's been no problem with
using from any of the languages used so far (python, java, glibc, c#,
Qt), In the documentation extensions, there's semantically meaningful
flag definitions [1]. Bitfields also allow you to have a single signal
tell you whats changed, so again reducing number of calls necessary.

i.e.
method GetCapabilities (in:, out:u)
signal CapabilitiesChanged (u)


Thanks,
Rob Taylor


[1] from
http://projects.collabora.co.uk/darcs/telepathy/telepathy-spec/spec/Connection_Manager.xml

    <tp:flags name="Conn_Mgr_Param_Flags"
value-prefix="Conn_Mgr_Param_Flag">
      <tp:flag suffix="Required" value="1">
        <tp:docstring>
          This parameter is required for connecting to the server.
        </tp:docstring>
      </tp:flag>
      <tp:flag suffix="Register" value="2">
        <tp:docstring>
          This parameter is required for registering an account on the
          server.
        </tp:docstring>
      </tp:flag>
      <tp:flag suffix="Has_Default" value="4">
        <tp:docstring>
          This parameter has a default value, which is returned in
          GetParameters; not providing this parameter is equivalent to
          providing the default.
        </tp:docstring>
      </tp:flag>
    </tp:flags>