Bug 25018

Summary:	ChannelRequest.Succeeded should give you the resulting channel
Product:	Telepathy	Reporter:	Will Thompson <will>
Component:	tp-spec	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED DUPLICATE	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	enhancement
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Will Thompson 2009-11-10 07:55:07 UTC

Suppose I want to write an application which places a call, and then do something when the call ends. Currently, I have to:

• Be an Observer for StreamedMedia channels;
• Call CD.CreateChannel(), get a ChannelRequest;
• Press Proceed() on the CR;
• When I get ObserveChannels called on me, check if Requests_Satisfied includes the CR I just got. If so, that's my channel, and I get to hook up a proxy and wait for it to be invalidated;
• When I get CR.Succeeded, I'd better hope that I've seen the channel as an observer (note that if MC hasn't finished introspecting me by the time I request the channel, it might not know I'm an observer yet).

If Succeeded gave me the channel, I could cut out all the observer crap, and just do:

• CreateChannel();
• Proceed();
• wait for Succeeded or Failed.

Comment 1 Simon McVittie 2010-07-13 03:57:23 UTC

See also the discussion on the mailing list in thread "On spec additions to allow a really simple IM API".

If we're enhancing channel-requesting, we should probably do Bug #28866 at the same time, to keep the number of "compatibility levels" manageable.

Comment 2 Guillaume Desmottes 2010-08-17 05:51:27 UTC

One way to do that would to add this signal on the ChannelRequest object:
SucceededWithChannel (o: Connection, o: Channel)

If the spec guarantees that this signal is fired *before* Succeeded() (if implemented) we should be good. Clients understanding the new signal will be done once any of the sig has been fired and old clients will continue to rely on Succeeded().

Comment 3 Simon McVittie 2010-08-17 05:56:05 UTC

(In reply to comment #2)
> One way to do that would to add this signal on the ChannelRequest object:
> SucceededWithChannel (o: Connection, o: Channel)

Yes, exactly, but:

(In reply to comment #1)
> If we're enhancing channel-requesting, we should probably do Bug #28866 at the
> same time, to keep the number of "compatibility levels" manageable.

My plan is that when we do Bug #28866 ((Create|Ensure)ChannelWithMetadata, although I might rename Metadata to Hints), we add SucceededWithChannel at the same time, and guarantee that any implementation of the former will implement the latter.

Then, tp_account_request_ensure_and_observe() would call EnsureChannelWithMetadata, even if the set of metadata is empty; if that method call succeeds, the client knows that it can expect to see SucceededWithChannel.

Comment 4 Guillaume Desmottes 2010-08-17 06:02:05 UTC

(In reply to comment #3)
> Then, tp_account_request_ensure_and_observe() would call
> EnsureChannelWithMetadata, even if the set of metadata is empty; if that method
> call succeeds, the client knows that it can expect to see SucceededWithChannel.

That's exactly what I had in mind as well :)

Comment 5 Guillaume Desmottes 2010-08-20 06:01:35 UTC

I have a spec branch and a proof of concept implementation of this. See https://bugs.freedesktop.org/show_bug.cgi?id=28866#c3

Comment 6 Guillaume Desmottes 2010-08-31 02:12:13 UTC

Should SucceededWithChannel include the properties of the Connection and the Channel?

Comment 7 Simon McVittie 2010-09-03 09:00:58 UTC

I think everyone agrees that this bug and Bug #28866 should be closed simultaneously, so let's move all discussion to that bug.

*** This bug has been marked as a duplicate of bug 28866 ***

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.