Use case: 1) Have a UOA/GOA facebook account 2) The access token expires 3) in UOA/GOA you re-grant the access so you get a new access-token 4) UOA/GOA MC plugin gets notified of that new access token and needs to trigger a reconnection to use it.
Here is a patch: http://cgit.collabora.com/git/user/xclaesse/telepathy-mission-control.git/log/?h=reconnect
> + return iface->reconnect (mcpa, account); "return x()", where x is a void function, is rejected by some C compilers. Remove "return". I'm not sure what our rule of thumb is for whether a storage plugin should emit a signal, or whether it should call a method on the McpAccountManager. This feels intuitively like a job for a signal to me, but I can't quite articulate why... It does occur to me that if the storage plugin emitted a signal, it could be caught by the McdAccountManager (which already has to listen for ::created, ::altered, etc. anyway) and there wouldn't be any need for additional boilerplate in McdStorage, which would be nice. (If you go the signal route, it might be nice to add a mcp_account_storage_emit_reconnect() that the plugin can call, so it doesn't need to mess about with g_signal_emit_by_name().)
(In reply to comment #2) > > + return iface->reconnect (mcpa, account); > > "return x()", where x is a void function, is rejected by some C compilers. > Remove "return". stupid mistake, wondering why my gcc is happy with it... Fixed. > I'm not sure what our rule of thumb is for whether a storage plugin should emit > a signal, or whether it should call a method on the McpAccountManager. This > feels intuitively like a job for a signal to me, but I can't quite articulate > why... > > It does occur to me that if the storage plugin emitted a signal, it could be > caught by the McdAccountManager (which already has to listen for ::created, > ::altered, etc. anyway) and there wouldn't be any need for additional > boilerplate in McdStorage, which would be nice. > > (If you go the signal route, it might be nice to add a > mcp_account_storage_emit_reconnect() that the plugin can call, so it doesn't > need to mess about with g_signal_emit_by_name().) Indeed that's seems easier like that. I was lost in all those ifaces/objects :( Branch updated.
(In reply to comment #3) > Branch updated. Ship it.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.