Bug 54539

Summary:	Storage plugins should be able to request a reconnection
Product:	Telepathy	Reporter:	Xavier Claessens <xclaesse>
Component:	mission-control	Assignee:	Xavier Claessens <xclaesse>
Status:	RESOLVED FIXED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium	Keywords:	patch
Version:	unspecified
Hardware:	Other
OS:	All
URL:	http://cgit.collabora.com/git/user/xclaesse/telepathy-mission-control.git/log/?h=reconnect
Whiteboard:	review+
i915 platform:		i915 features:

Description Xavier Claessens 2012-09-05 08:13:41 UTC

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.

Comment 1 Xavier Claessens 2012-09-05 08:14:39 UTC

Here is a patch: http://cgit.collabora.com/git/user/xclaesse/telepathy-mission-control.git/log/?h=reconnect

Comment 2 Simon McVittie 2012-09-05 08:50:09 UTC

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

Comment 3 Xavier Claessens 2012-09-05 10:49:28 UTC

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

Comment 4 Simon McVittie 2012-09-05 10:56:50 UTC

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