Bug 28695

Summary:	Need to clarify which codecs changed when a new CodecOffer comes in
Product:	Telepathy	Reporter:	Sjoerd Simons <sjoerd>
Component:	tp-spec	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED FIXED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium	Keywords:	patch
Version:	unspecified
Hardware:	Other
OS:	All
URL:	http://git.collabora.co.uk/?p=user/jonny/telepathy-spec.git;a=shortlog;h=refs/heads/codec-offers
Whiteboard:	Call
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	29590
Attachments:	Put only one Contact per CodecOffer fix your branch

Description Sjoerd Simons 2010-06-23 07:45:35 UTC

From #24936

CodecOffer (and the NewCodecOffer signal) should offer a way for the streaming
implementation to know which codecs changed and which didn't. It's not clear to
me if it contains the codecs from everyone or just from those who
joined/changed.

Comment 1 Olivier Crête 2010-08-16 10:24:30 UTC

Created attachment 37904 [details] [review]
Put only one Contact per CodecOffer

Giving all the codecs of all the users is a bad idea. It can not happen atomically. The current spec is not implementable as-is.

One CodecOffer should contain codecs from only one contact. Either we keep on having one codec offer at a time and the CM decides the order. Or we can can replace the CodecOffer property with "CodecOffers" and have an array of offers.

Comment 2 Olivier Crête 2010-10-20 07:26:29 UTC

Another option is to define the API as the following:

they will all be applied in order, if one fail, then rest will on be tried (and then we need to say which one was rejected in the Reject() call)

But it seems easier to accept/reject them one at a time.

Comment 3 Jonny Lamb 2010-10-25 09:36:17 UTC

Sjoerd and ÔlÎvÎÊr say ja oui yes to this.

Splendid.

In reality they will only come one at a time (in muji). Okay, good.

Comment 4 Jonny Lamb 2010-10-26 09:20:43 UTC

See my branch.

Comment 5 Sjoerd Simons 2010-10-29 10:30:15 UTC

I don't think there is much of a point of having a mapping to multiple codec offers, if we say they come one by one they should just come out of the interface one by one (the CM can just queue them)

Comment 6 Jonny Lamb 2010-10-30 11:28:16 UTC

(In reply to comment #5)
> I don't think there is much of a point of having a mapping to multiple codec
> offers, if we say they come one by one they should just come out of the
> interface one by one (the CM can just queue them)

So are you happy with my branch without the most recent commit, 80a88995ea?

Comment 7 Olivier Crête 2010-10-31 18:35:40 UTC

Created attachment 39938 [details] [review]
fix your branch

here is a patch against your branch that does the right thing I believe.

Comment 8 Sjoerd Simons 2010-11-04 04:16:01 UTC

Combined jonny's top patch and oliviers patch, with some extra goodness of my own and merged it to master, thanks guys!

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.