[Bug 29914] Add idleness connection interface

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Sep 3 11:40:41 CEST 2010


https://bugs.freedesktop.org/show_bug.cgi?id=29914

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
  Status Whiteboard|                            |review+ as draft, minor
                   |                            |changes
           Keywords|                            |patch
         AssignedTo|telepathy-bugs at lists.freede |eitan.isaacson at collabora.co
                   |sktop.org                   |.uk

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-09-03 02:40:41 PDT ---
This looks OK as a first draft, if the following changes are made:

I'd prefer the name SetPowerSaving rather than TogglePowerSaving - its
semantics are currently set rather than toggle, because toggle means "let x =
!x", which is never what we want on D-Bus (because if two processes toggle at
the same time, you lose).

I'd prefer the interface to be named PowerSaving rather than PowerSave.

> +            connection can have it's powersaving mode turned on or off.</p>

have its power saving mode

> +        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
> +          <tp:docstring>
> +            The current connection has no power saving features.

I don't think this is useful. I think SetPowerSaving(TRUE) should mean "consume
minimum power" and FALSE should mean "behave normally"; on an XMPP connection
that lacks power-saving extensions like GTalk's, minimum power and behaving
normally are the same thing :-)

The only cases in which I'd expect Gabble to raise an error from this method
would be if sending the stanza to the server failed, e.g. NetworkError (but
that's a ridiculous edge-case which should only happen if we're about to drop
off the network anyway), or if we sent the stanza to the server and it replied
with an error (which might well be mapped to NotAvailable, hence my concern).

--------------------------------------------------

This interface doesn't mention what you lose by enabling power saving. We
should say what the power saving flag breaks, so that clients can choose when
to set it in an appropriate way.

I believe that in practice, power saving suppresses the sorts of things that
you don't care about notifications for until your display is lit - presence
updates, and hence the ability to get up-to-date capabilities and avatars -
while not suppressing channels or publish requests (which could be thought of
as communication types). Is this true?

A more overengineered version of this interface would be to have a bitfield of
"things I'm prepared to sacrifice in order to save power", and to have the CM
decide what to do based on that, e.g.:

    SetPowerSaving (Presence | Capabilities | Avatars | Calls)

If we did that, Gabble on GTalk would only go to power-saving mode if the first
three of those flags were all set, and could stop advertising Jingle
capabilities if the Calls flag was set. (Silly hypothetical example, we
probably wouldn't actually want to do that - although in principle we could
stop being callable while on the last 10% of battery or something...)

I think that's probably overkill, but it seems worth at least mentioning it!

--------------------------------------------------

An alternative approach worth mentioning here would be to have a service name
ofdT.PowerSaving (in practice yet another name for MC), have it emit signals,
and have CMs listen for those. That would break the general design that CMs are
"at the bottom of the stack" (always emit signals and have methods called on
them), though.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.



More information about the telepathy-bugs mailing list