[Bug 29914] Add idleness connection interface

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Eitan Isaacson <eitan.isaacson at collabora.co.uk> 2010-09-03 10:06:17 PDT ---
(In reply to comment #4)
> 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).
> 

Yup. b4b2e04

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

7bbfa3c

> > +            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 :-)

If the CM cannot switch modes, either because of the protocol (NotImplemented),
or because of the service (NotAvailable), I think MC (or whoever manages this)
should be made aware. They could ignore it or, in the extreme, be fascist and
disconnect the account.

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

Functionally, there is no difference. In the XMPP case, gabble will get a
<service-unavailable/> error if the server does not support google's queueing,
which will be mapped to a Telepathy NotAvailable error. So we are basically
saying the same thing.

You think this should not be explicitly mentioned in the docs?

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

Yeah, I'll make it clear in the docs. Power saving should be used when the user
is not interacting with the device, for example when the screen is locked.

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

I think the encapsulation here is nice. It is up to the CM to be creative and
figure out how to take power saving measures with no noticeable effects to the
user.

An earlier version of the draft used a two member enum instead of binary
on/off. I was thinking it would make it future-proof if we ever invent
intermediate power saving modes. But I couldn't think of real world examples,
so I dropped 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.

Yeah, I think that would be a significant pattern change (is there precedent?).
Anyway, I think having this as a simple interface on the CM is very elegant.

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