The Channels property on ChannelDispatchOperation objects is mutable (channels can fall off). However, AddDispatchOperation documentation implies that it is immutable. We should separate the Channels into a separate argument, and document the inherent race conditions. For reference, those races are: * channels that close immediately after AddDispatchOperation go bad - the approver should call a method on the channel (i.e. make a TpChannel) to notice whether they're dead or not * channels that close immediately after HandleChannels is called - the handler should do the same
Discussion with Rob resulted in this proposal: * CDOs' Channels property remains mutable * CDOs aren't allowed to emit ChannelLost or Finished until all approvers have returned from AddDispatchOperation (they should queue up the signals for later sending if necessary) * As a result, Approvers * Non-Approvers that are somehow given a CDO's object path (i.e. mostly Observers) are required to connect to ChannelLost, connect to Finished and GetAll(), as per the usual connect-signals-before-state-recovery doctrine I'll spec it up on Monday.
(In reply to comment #1) > * As a result, Approvers This sentence doesn't seem to
Should have been: * As a result, Approvers may assume that Channels stays constant at least until they return from ADO, so they have time to connect to ChannelLost
http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/approver-abibreak
Yes (specmeet)
Fixed in git, will be in 0.17.23, MC needs to catch up (Bug #21174)
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.