[Bug 31274] Call: NewCodecOffer signal should contain the properties of the optional CodecOffer interfaces

[bugzilla-daemon at freedesktop.org]

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

--- Comment #9 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-01-10 06:26:35 PST ---
> +      <p> If the remote codecs and other content information is available

trivia: are available

> +         >NoRemoteInformation</tp:dbus-ref> property will be false

I'm a bit hesitant to have "negative" boolean properties if there's no good
reason for it (so I'd prefer to define HasRemoteInformation to be the inverse
of your NoRemoteInformation, and remove NoRemoteInformation).

>        <h4>Changing codecs mid-call</h4>
> ...
> +        accepted, then 

trivia: trailing whitespace after "then"

+      <tp:member name="Remote_Contact" type="u" tp:type="Handle">
+        <tp:docstring>
+          The remote contact this description refers to
+        </tp:docstring>

Can this be 0?

+      <tp:docstring>
+        <p>A map from contact handles to the descriptions as response.</p>

This could do with expanding. Do you mean: each key is a remote contact handle
(is 0 allowed here btw?), and depending how far into the negotiation we've got,
the value is either the description we have offered to that remote contact, or
the intersection of local/remote descriptions that we have negotiated with the
remote contact?

+      <arg name="MediaDescription" type="o">

trivia: Ugly_Case please (it matters somewhat in Qt-land)

In LocalMediaDescriptionsChanged and RemoteMediaDescriptionsChanged, is the map
a diff, or a new value for the property? (I assume it's a diff, so keys that
are omitted from the change notification stay the same.)

+      <arg name="Removed_Media_Descriptions" type="au">

tp:type="Contact_Handle" I assume? It'd be nice to clarify that members of this
list are removed from the keys of both maps (I assume that that's what
happens).

+    <property name="MediaDescriptionOffer"

In a multi-user call, can we have more than one of these active? I assume the
answer must be "no" - is that because it can't arise anyway, or is it enforced
by the CM not announcing a new media description until the previous one has
been processed?

         <p>Change notification is via the
+          <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> and
+          <tp:member-ref>MediaDescriptionOfferDone</tp:member-ref> signal.

trivia: ... signals.

+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      This object represents a remote Description Offer to which the local
+      streaming implementation should reply with its local Description
+    </tp:docstring>

If Description is well-known jargon, perhaps you could hyperlink to SDP or
Jingle or something for the definition?

+        <p>Extra interfaces provided by this codec offer.  This SHOULD
+          NOT include the Description interface itself, and cannot change
+          once the content has been created.</p>

trivia: this is neither a codec offer nor a content

+    <method name="Reject" tp:name-for-bindings="Reject">
+      <tp:docstring>
+        Reject the proposed update to the remote description
+        FIXME add error codes and strings here
+      </tp:docstring>
+    </method>

I hope there's a bug for that :-)

+        <p> This property will never be part of the DescriptionProperties used
+            to describe this object. If this property is true then the
+            DescriptionProperties describing this object will be empthy (as
+            there is no remote information to put in it)

empty

DescriptionProperties seems like a dangling reference, which should be to
Media_Description_Properties; but you seem to be using
Qualified_Property_Value_Map directly, elsewhere.

Is the contact handle in a Media_Description_Offer and/or
Contact_Media_Description_Properties_Map redundant with the
MediaDescription.RemoteContact?

Please open a bug for the Remote_Contact = 0 thing, unless you plan to leave
this bug open after merging to represent it.

-- 
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.