_mcd_account_needs_dispatch(), also known as the always_dispatch struct member and attribute, has two orthogonal functions: * flags the account as OK to connect even when the McdConnectivityMonitor thinks it shouldn't (suspending, no network, etc.) * in mcd_connection_need_dispatch(), if a non-MC client has requested channels by "going behind MC's back", we would normally only pass them to Observers, but if the account has always_dispatch, we pass them to Handlers too (potentially leading to the non-MC client and the Handler fighting over the channel) In practice, always_dispatch means "is telepathy-ring". We should have a more reasonable API for these things, driven by what Telepathy users actually need.
(In reply to comment #0) > * flags the account as OK to connect even when the McdConnectivityMonitor > thinks it shouldn't (suspending, no network, etc.) Short-term: replace this with: is the account's protocol "tel"? Long-term: maybe add a flag on Protocol, "doesn't need network connectivity". Looking at what McdConnectivity does, we could perhaps combine this with flags for "OK to leave connected while suspended", "OK to leave connected while networking is in flux", and "OK to leave connected while shutting down". In theory, telepathy-salut could have "doesn't need connectivity", although that would be somewhat misleading (UIs would show you as still online) so perhaps best not to. It can certainly have "doesn't need a default gateway", if we get that as a flag.
(In reply to comment #0) > * in mcd_connection_need_dispatch(), if a non-MC client has requested > channels by "going behind MC's back", we would normally only pass them > to Observers, but if the account has always_dispatch, we pass them > to Handlers too (potentially leading to the non-MC client and the Handler > fighting over the channel) I believe the original motivation for this was something like: on a phone, if an app initiates a call (even if it does it "the wrong way"), it's really bad for it not to pop up the big obvious "you're on the phone" UI. I suspect that we don't really need this: 1) If you want to guarantee that (at least part of) the call UI is present for every call, it can just as easily be an Observer, which you might well want it to be anyway. 2) This is either a guard against malice or incompetence. If it's to guard against malicious applications, you already need some sort of security framework to stop those applications ptrace()ing Mission Control or telepathy-ring and subverting them, or sending a million SMSs (via the intended API!) and being expensive, or making outgoing calls while idle in order to spy on you. If it allows untrusted apps to be on the session bus directly at all (which might itself not be such a good idea), then that security framework can (presumably) prevent applications from calling methods on telepathy-ring, specifically its Connection.Interface.Requests and Channel.Type.Text. As of Telepathy 1.0, Connection.Interface.Requests will be the only way to request channels behind Mission Control's back, because the Connection.RequestChannel method has been removed. If it's to guard against incompetent applications, you can either say "fix them, then" or use similar strategies.
(In reply to comment #1) > (In reply to comment #0) > > * flags the account as OK to connect even when the McdConnectivityMonitor > > thinks it shouldn't (suspending, no network, etc.) > > Short-term: replace this with: is the account's protocol "tel"? This is acceptable, but no cleaner than the always-dispatch flag. > Long-term: maybe add a flag on Protocol, "doesn't need network connectivity". > > Looking at what McdConnectivity does, we could perhaps combine this with > flags for "OK to leave connected while suspended", "OK to leave connected > while networking is in flux", and "OK to leave connected while shutting > down". Would this mean that the setting is immutable without modifying the CM itself? For a simple "needs connectivity" flag that would probably be OK, but for something more nuanced like "OK to leave connected while suspended", it may need to be modified on a device or even account level. (In reply to comment #2) > (In reply to comment #0) > > * in mcd_connection_need_dispatch(), if a non-MC client has requested > > channels by "going behind MC's back", we would normally only pass them > > to Observers, but if the account has always_dispatch, we pass them > > to Handlers too (potentially leading to the non-MC client and the Handler > > fighting over the channel) > > I believe the original motivation for this was something like: on a phone, > if an app initiates a call (even if it does it "the wrong way"), it's really > bad for it not to pop up the big obvious "you're on the phone" UI. > > I suspect that we don't really need this: > > 1) If you want to guarantee that (at least part of) the call UI is present > for every call, it can just as easily be an Observer, which you might well > want it to be anyway. > > 2) This is either a guard against malice or incompetence. > [snip] > If it's to guard against incompetent applications, you can either say "fix > them, then" or use similar strategies. I agree. That can be removed entirely.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/issues/76.
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.