[Bug 55391] stop MC using things deprecated in 0.20

[bugzilla-daemon at freedesktop.org]

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

--- Comment #32 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #29)
> I'm not sure to understand why plugins needs to subclass
> McpDispatchOperation

They don't. It's a GInterface, and MC implements it.

The point is to make it completely obvious what API plugins are allowed to use
to call back into Mission Control: they are allowed to use the public symbols
from libmission-control-plugins, and nothing else.

> but I think in next, we should have a mandatory
> construct-only "factory" property and
> mcp_dispatch_operation_ref_connection() can then use self->priv->factory.

I feel as though it ought to be using a factory supplied (or at least chosen)
by the plugin, rather than MC's internal TpSimpleClientFactory: the features MC
chooses to prepare shouldn't affect plugins, and vice versa. This means plugins
use distinct TpConnection objects (etc.) for the same remote object
(duplication in memory), but also avoids MC and plugins unintentionally
affecting each other's behaviour.

(Or perhaps plugins that don't express any particular opinion on the matter
should share a TpSimpleClientFactory with each other, but not with MC?)

I don't particularly want plugins to be able to stall MC dispatching by mistake
by insisting that it prepares TP_CONNECTION_FEATURE_SOME_SLOW_THING before it
gets on with its work - TP_CONNECTION_FEATURE_CONNECTED is particularly nasty,
because MC is one of the few applications that will do useful (and
asynchronous!) things before the connection goes CONNECTED.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.