Summary: | TpCallContentMediaDescription should implement extra interfaces | ||
---|---|---|---|
Product: | Telepathy | Reporter: | Xavier Claessens <xclaesse> |
Component: | tp-glib | Assignee: | Telepathy bugs list <telepathy-bugs> |
Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | olivier.crete |
Version: | unspecified | Keywords: | patch |
Hardware: | Other | ||
OS: | All | ||
URL: | http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/log/?h=call1-md | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Xavier Claessens
2012-03-07 01:02:38 UTC
Done in my call1-md branch: http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/log/?h=call1-md Added a couple fixes/improvements on your branch http://cgit.collabora.com/git/user/tester/telepathy-glib.git/log/?h=call1-md Also, I've implemented support in tp-gabble http://cgit.collabora.com/git/user/tester/telepathy-gabble.git/log/?h=call1-md Both branches should probably gain unit tests. The problem with those function that just add the interface, is that they leave properties undefined. If I understand correctly, the goal is to be able to implement the ifaces with HeaderExtensions and/or FeedbackMessages empty, right? In that case, I'm ok with tp_call_content_media_description_add_rtp_header_extensions_interface() since that iface has no other properties. But tp_call_content_media_description_add_rtcp_feedback_interface() is useless since you need to define does-avpf so just calling tp_call_content_media_description_set_does_avpf() is better. And tp_call_content_media_description_add_rtcp_extended_reports_interface() is useless since you need to define all properties anyway with tp_call_content_media_description_set_rtcp_extended_reports(). For all these cases, the user case is the initial offer. The goal is to tell tp-fs which interfaces the CM supports. There are no change notification, so all those properties should be marked immutable, right? Spec could be fixed to mark them immutable btw. So there is no point in telling an interface is implemented if we don't give the value for its properties... or there is something I don't understand... The first offer is empty and asks the Client to fill it, but the client has to know which interfaces are available and which aren't. ok now I understood. Merged the branch. |
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.