[Bug 24906] GSM-compatible conference calls

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=24906

--- Comment #27 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-14 11:04:54 PDT ---
(In reply to comment #25)
> (In reply to comment #23)
> > Is there a specific bit of information that's too hard in the Group interface,
> > and can we fix it in Group instead? (Note that telepathy-qt4 and telepathy-glib
> > both provide some convenience API for Groups.)
> 
> The channel-specific handles might make the Group interface inconvenient
> compared to tracking the ChannelMerged and ChannelRemoved signals.

If we do this:

(In reply to comment #23)
> Perhaps we should define that if the channel was removed because it terminated,
> then the channel must signal that it closed (and hopefully why) before
> ChannelRemoved is signalled?

and we also make ChannelMerged contain the immutable properties, then I think
that's sufficient to tell you what's going on?

* on startup, make a TpChannel for each channel in Channels

* on ChannelMerged, make a TpChannel for it (using those immutable properties)
and put it in a map { object path => TpChannel }

* on ChannelRemoved, look up the TpChannel and see whether it has been
invalidated yet (or, for Call channels, whether it has moved to Error state).
If it has, tp_proxy_get_invalidated() (or for Call channels, a yet-to-be-added
accessor) tells you the error; if it hasn't, then by elimination, the reason
for removal must have been that it was detached.

Does that seem reasonable?

On StreamedMedia, the sub-channel's TpChannel will automatically pick up the
error reason from its Group interface without your help, hence the ability to
use TpProxy:invalidated.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.