|Summary:||call Observers, even if channels have no Handler|
|Product:||Telepathy||Reporter:||Simon McVittie <smcv>|
|Component:||mission-control||Assignee:||Simon McVittie <smcv>|
|Status:||RESOLVED FIXED||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|i915 platform:||i915 features:|
|Bug Depends on:|
fd.o #34025 (ish): if we handle a channel internally, record that fact
McdHandlerMap: add brief documentation
fd.o #29022: if a channel can't be handled, dispatch it anyway, to run observers
undispatchable test: assert that observers are invoked, but approvers are not
Description Simon McVittie 2010-07-12 10:17:56 UTC
By inspection of the source code, if a dispatch operation has no PossibleHandlers, MC doesn't seem to dispatch it to observers or to approvers. test/twisted/dispatcher/undispatchable.py should create a Text Observer and a Text Approver, and assert whether their methods are called. However, it doesn't. I think Observers should be invoked for undispatchable operations (rationale: implementing ObserveChannels should be like listening for NewChannels). I'm not so sure about Approvers. In favour of running Approvers if there's no Handler: + consistent with observers + maybe the Approver can arrange for a non-service-activatable Handler to be started out-of-band + maybe the Approver knows out-of-band that an existing Handler can secretly handle the channel, even though its filter says otherwise (symmetry with the PreferredHandler overriding filters) Against running Approvers if there's no Handler: - until now, if the Approver calls HandleChannels("") and gets an error, it's always an error from the Handler; now, HandleChannels("") has to be able to return a specified error that means "actually, I can't do that" - if the Approver blindly calls HandleChannels(Possible_Handlers), it'll crash itself ("don't do that then" is a reasonable answer) - Approvers are for interactive approval: is it really appropriate for an interactive approver to pop up if approval is impossible anyway? If you have some UI for "smcv is sending you a file [Save] [Reject]", would it ever make sense for it to pop up to say "smcv is sending you a file but you can't receive it [OK]", and would Approver authors actually deal with this correctly anyway? (It would be rubbish UI to have a popup that says "smcv is sending you a file [Save] [Reject]", and then when you click Save, have an error message "you can't receive files".) One possible solution is to let Approvers set a flag for whether they want to be nagged about undispatchable channels, with the default being FALSE (because that's the one that doesn't need the Approver author to take any other special action).
Comment 1 Simon McVittie 2011-05-19 08:44:15 UTC
(In reply to comment #0) > I think Observers should be invoked for undispatchable operations (rationale: > implementing ObserveChannels should be like listening for NewChannels). This is so straightforward that I think we should JFDI. > I'm not > so sure about Approvers. This is tricky, so I cloned it to the spec. Bug #37373.
Comment 2 Simon McVittie 2011-05-19 10:19:30 UTC
Here's a branch.
Comment 3 Marco Barisione 2011-07-07 11:51:38 UTC
Simon, the URL is not accessible anymore.
Comment 4 Simon McVittie 2011-07-11 01:39:29 UTC
Created attachment 48954 [details] [review] fd.o #34025 (ish): if we handle a channel internally, record that fact This means we'll include it in the set of handled channels when we invoke Observers with Recover=TRUE. We don't do this when calling _mcd_request_handle_internally (., ., FALSE) since we're not really behaving like a Handler in that case - more like an Observer or something.
Comment 5 Simon McVittie 2011-07-11 01:39:48 UTC
Created attachment 48955 [details] [review] McdHandlerMap: add brief documentation
Comment 6 Simon McVittie 2011-07-11 01:40:21 UTC
Created attachment 48956 [details] [review] fd.o #29022: if a channel can't be handled, dispatch it anyway, to run observers Arguably, we should have some way that approvers can opt-in to being told about undispatchable channels that they might want to Claim, but that requires spec, whereas we can fix this straight away.
Comment 7 Simon McVittie 2011-07-11 01:40:51 UTC
Created attachment 48957 [details] [review] undispatchable test: assert that observers are invoked, but approvers are not Also assert that MC doesn't close the channel as undispatchable until the Observer has had a look at it. (That's all the patches.)
Comment 8 Simon McVittie 2011-07-11 01:45:45 UTC
(In reply to comment #3) > Simon, the URL is not accessible anymore. Migrated to freedesktop.org, but not in cgit til the cron job runs; see attached patches or add ssh://people.freedesktop.org/~smcv/telepathy-mission-control.git as a remote.
Comment 9 Will Thompson 2011-09-07 09:26:20 UTC
Fixed in 5.8.1 and in the soon-to-be-released 5.9.2.