Bug 52305

Summary: dispatch each channel separately
Product: Telepathy Reporter: Simon McVittie <smcv>
Component: mission-controlAssignee: Simon McVittie <smcv>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium CC: jonny.lamb
Version: unspecifiedKeywords: patch
Hardware: Other   
OS: All   
URL: http://cgit.freedesktop.org/~smcv/telepathy-mission-control/log/?h=one-channel-should-be-enough-for-anyone
Whiteboard: review+
i915 platform: i915 features:
Attachments: McdConnection: remove virtual methods
McdConnection: dispatch each channel from NewChannels separately
_mcd_dispatcher_take_channels: make singular, rename to ...add_channel
mcd_dispatcher_dup_possible_handlers: only take one TpChannel
_mcd_client_registry_list_possible_handlers: only take one channel
_mcd_dispatcher_enter_state_machine: only take one channel
McdDispatchOperation: remove untrue comment
McdDispatchOperation: change channels property to channel (singular)
_mcd_dispatch_operation_peek_channel: adapt from old _peek_channels
McdDispatchOperation: use internal list instead of dup_channels()
_mcd_dispatch_operation_dup_channels: turn into dup_channel, singular
_mcd_dispatch_operation_new: only take one channel
Replace iteration over channels with check for having a channel
McdDispatchOperation: collect_satisfied_requests: only take one channel
McdDispatchOperation: store one McdChannel, not a list
McdDispatchOperation: only have one lost_channel, too

Description Simon McVittie 2012-07-20 12:21:16 UTC
NewChannels with a number of channels other than one is deprecated, because in practice, no client handles it correctly. We're gradually removing this usage from connection managers.

To reduce client confusion even before we've fixed all the CMs, we could modify MC to dispatch channels one at a time. This cascades into quite a lot of simplification in McdDispatchOperation etc., where lists become single nullable channels.

I have a branch, but it's based on some unrelated (and quite extensive) refactoring. I'm rebasing it.
Comment 1 Simon McVittie 2012-07-20 13:45:06 UTC
Created attachment 64431 [details] [review]
McdConnection: remove virtual methods

Now that embedding and old-style plugins have been abolished, nothing
can override them.
Comment 2 Simon McVittie 2012-07-20 13:45:25 UTC
Created attachment 64432 [details] [review]
McdConnection: dispatch each channel from NewChannels  separately

This loses information - you can no longer tell the channels are
related - but in practice nobody handles Text and Tube channels as a
unit anyway, and signalling them together is now deprecated.
Comment 3 Simon McVittie 2012-07-20 13:45:38 UTC
Created attachment 64433 [details] [review]
_mcd_dispatcher_take_channels: make singular, rename  to ...add_channel

It was previously (transfer container), now it's (transfer none).
Comment 4 Simon McVittie 2012-07-20 13:46:08 UTC
Created attachment 64436 [details] [review]
mcd_dispatcher_dup_possible_handlers: only take one  TpChannel
Comment 5 Simon McVittie 2012-07-20 13:46:29 UTC
Created attachment 64437 [details] [review]
_mcd_client_registry_list_possible_handlers: only take  one channel
Comment 6 Simon McVittie 2012-07-20 13:47:09 UTC
Created attachment 64438 [details] [review]
_mcd_dispatcher_enter_state_machine: only take one  channel
Comment 7 Simon McVittie 2012-07-20 13:47:30 UTC
Created attachment 64439 [details] [review]
McdDispatchOperation: remove untrue comment

I dimly remember that _mcd_dispatch_operation_new once had
(transfer container) or possibly even (transfer full) semantics for the
list of channels, but I also dimly remember removing it. The
implementation certainly has (transfer none) semantics, and its one
caller behaves as such too.
Comment 8 Simon McVittie 2012-07-20 13:48:09 UTC
Created attachment 64440 [details] [review]
McdDispatchOperation: change channels property to  channel (singular)
Comment 9 Simon McVittie 2012-07-20 13:48:34 UTC
Created attachment 64441 [details] [review]
_mcd_dispatch_operation_peek_channel: adapt from old  _peek_channels

Now that the CDO can contain at most one channel, there's no need to
return a list.
Comment 10 Simon McVittie 2012-07-20 13:49:21 UTC
Created attachment 64442 [details] [review]
McdDispatchOperation: use internal list instead of  dup_channels()

Now that there can only be at most one channel in the list, it's
pretty easy to do directly.
Comment 11 Simon McVittie 2012-07-20 13:49:36 UTC
Created attachment 64443 [details] [review]
_mcd_dispatch_operation_dup_channels: turn into   dup_channel, singular
Comment 12 Simon McVittie 2012-07-20 13:49:50 UTC
Created attachment 64444 [details] [review]
_mcd_dispatch_operation_new: only take one channel
Comment 13 Simon McVittie 2012-07-20 13:50:10 UTC
Created attachment 64445 [details] [review]
Replace iteration over channels with check for having  a channel

Now that there can only be one channel, we don't need to iterate.
Comment 14 Simon McVittie 2012-07-20 13:50:25 UTC
Created attachment 64446 [details] [review]
McdDispatchOperation: collect_satisfied_requests: only  take one channel
Comment 15 Simon McVittie 2012-07-20 13:50:42 UTC
Created attachment 64447 [details] [review]
McdDispatchOperation: store one McdChannel, not a list
Comment 16 Simon McVittie 2012-07-20 13:50:57 UTC
Created attachment 64448 [details] [review]
McdDispatchOperation: only have one lost_channel, too
Comment 17 Jonny Lamb 2012-07-23 18:13:50 UTC
Yeah this looks fine. I was going to comment on how there are a couple of FIXMEs added, but yeah whatever. I also didn't really review every change to the test suite — you probably got it right.

Hot.
Comment 18 Jonny Lamb 2012-07-23 18:14:16 UTC
Sorry, I mean:

 m    m          m          
 #    #  mmm   mm#mm        
 #mmmm# #" "#    #          
 #    # #   #    #          
 #    # "#m#"    "mm    #
Comment 19 Simon McVittie 2012-08-27 10:52:29 UTC
Fixed in master for 5.13.1, thanks.

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.