Bug 20031

Summary: PendingChannel can't wait for ready
Product: Telepathy Reporter: Simon McVittie <smcv>
Component: tp-qtAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED NOTABUG QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Simon McVittie 2009-02-10 03:50:55 UTC
The current implementation of PendingChannel requires library users to take two asynchronous steps rather than one:

* call createChannel() or ensureChannel()
* wait asynchronously for the resulting PendingChannel to finish
* in the finished handler, call channel() on the PendingChannel
* call becomeReady(...) on the resulting Channel
* wait asynchronously for the resulting PendingOperation to finish

This isn't necessarily ideal, and it'd be good to have a way to squash the two async steps into one.

However, it does have some advantages:

* a user that doesn't actually want the Channel object can avoid constructing it altogether (a ChannelDispatcher implementation shouldn't need these objects, only the QVariantMaps containing their immutable properties)
* it's easy for a user to make a different subclass of Channel, by passing the info available on the PendingChannel object to some other constructor

Thoughts? When we've decided the way forward, we can close this bug as INVALID, or fix it.
Comment 1 George Goldberg 2009-02-10 05:55:31 UTC
When using TpQt4, I initially found the current approach quite annoying because of the extra async operation, but actually I think I am in favour of keeping it as it is. The extra flexibitity is very useful (yes I'm biased because I'm doing so much coding on Qt telepathy stack infrastructure so need all the corner cases, but it still counts). Also, usint TpQt4 requires so many async operations that I don't think a few more really makes it any more difficult to be honest.
Comment 2 Andre Moreira Magalhaes 2009-04-23 07:10:30 UTC
We decided to keep using this approach as it's needed in some cases, custom channel, for example. So closing this bug.

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.