#2412 BLOC First D: Buddies not disappearing even when connection does

[Zarro Boogs per Child]

#2412: Buddies not disappearing even when connection does
-------------------------------+--------------------------------------------
  Reporter:  Zack              |       Owner:  smcv                  
      Type:  defect            |      Status:  new                   
  Priority:  blocker           |   Milestone:  First Deployment, V1.0
 Component:  presence-service  |     Version:                        
Resolution:                    |    Keywords:  collaboration         
  Verified:  0                 |  
-------------------------------+--------------------------------------------

Comment(by morgs):

 Replying to [comment:20 smcv]:
 > morgs, could you please check the Presence Service code? Don't
 necessarily fix anything right now (though that'd be good) but it'd be
 useful to know the status.
 >
 > - When connections signal that they have become disconnected via the
 Telepathy API, ensure that we remove the relevant handle from all buddies
 on that connection, causing them to emit BuddyDisappeared if they are not
 visible on any other connection

 Looks like we don't.

 > - When Gabble becomes disconnected, ensure that we bring Salut back up

 We do.

 > - When N-M reports a disconnection, do we forcibly close Gabble
 connections?

 We do self._conn[CONN_INTERFACE].Disconnect() (wrapped in an evil try:
 except: pass)

 > If the answer to the second point is "no", I'm not convinced we should.
 It's entirely possible that after a transient disconnection +
 reassociation we'd come back online with the same IP address and our
 connections would be unaffected, so perhaps instead of forcibly closing
 Telepathy connections when N-M says we went offline, we should set some
 arbitrary timer and forcibly close the connection when it expires, unless
 we've gone back online with the same address in the meantime.
 >
 > It probably makes sense to close Gabble connections immediately if our
 IP address changes from one non-empty value to another, though, since that
 means we lose continuity anyway.

 I agree - but we don't do anything currently in this case.

 > Salut has its own internal logic for presence advertisements (and hence
 buddies' presence) timing out (it uses the recommended mDNS TTLs) so it
 never makes sense to kill the Salut connection due to disconnection. It
 also makes sense to have Salut running even when we're not on any network
 - Avahi does the right thing in any case, and the Salut "connection" being
 "connected" just means Salut is talking to Avahi.

 AFAICT Salut always runs when gabble doesn't, assuming it can see avahi on
 the system bus. Only gabble starting stops salut.

-- 
Ticket URL: <https://dev.laptop.org/ticket/2412#comment:21>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system