[Bug 29981] Support power saving interface

[bugzilla-daemon at freedesktop.org]

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

--- Comment #7 from Eitan Isaacson <eitan.isaacson at collabora.co.uk> 2010-09-09 10:47:54 PDT ---
(In reply to comment #5)
> > > -  /* We can only cork presence updates on Google Talk. Of course, the Google
> > > -   * Talk server doesn't advertise support for google:queue. So let's use the
> > > -   * roster again... */
> > > -  if (!(conn->features & GABBLE_CONNECTION_FEATURES_GOOGLE_ROSTER))
> > > -    return;
> > > 
> > > This check appears to have been lost, so we're sending commands to the server
> > > without checking if it supports them. What we should do instead is not include
> > > Connection.Interface.PowerSave in Connection.Interfaces if we're not on a
> > > Google connection (so that MC knows not to bother telling Gabble the activity
> > > status has changed), and probably also return an error from the method on
> > > PowerSave() if someone decides to call it anyway.
> > > 
> > 
> > I am not sure why that comment is there. "google:queue" does not get advertised
> > in the connection disco. So the only way to know is trial and error (ie.
> > SetPowerSaving and catch NotAvailable exception).
> 
> I know google:queue is not advertised. That's why the quoted-as-deleted code
> above says exactly that, and explains that it's using the presence
> google:roster to indicate that we're on a Google server. This isn't strictly
> right, but it does work.

I guess I should read more than 3 words in before commenting :P

I see Conn.I.PowerSaving being useful for offline connections as well, but I am
not totally convinced about it. You could sway me either way. If we use this
iface on offline accounts, we don't need to piggyback on top of google:roster,
we will just always sport the iface, and raise NotAvailable if the service does
not support it. Added bonus - non-google servers could support google:queue and
we would interop with them, even if they don't support google:roster.

> 
> > > The test should check what happens if Gabble's still waiting for a reply to a
> > > <queue/> request when it's disconnected. I think the contact search tests have
> > > an example of how to do this: you pass some EventPatterns to a helper function
> > > that deals with the disconnection; so here we should presumably expect the
> > > Cancelled error or something.
> > > 
> > 
> > This would not really be regarded as an error, so if the connection drops
> > before we get an ack, we will reënable presence queuing the next time it
> > connects.
> 
> Yes, but it might crash. Stuff crashing if it's waiting for an IQ reply when we
> disconnect is incredibly common.

I added a test locally, it doesn't crash Gabble, but I don't know how to
programmatically test for this. The search tests asserts that CreateChannel
raises a Disconnected error. I guess if Gabble crashed we would catch the
non-zero exit?

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