On 19/07/2013 6:55 AM, Kiran Kumar wrote:
> Dear Gili,
> Thanks for the comment.
>
> The suggested video is good.
>
> I just want to explain that, in future, SDP mangling may
> not be used that much, which can be achieved by constraints API. I am
> not mapping SDP and Constraints API, but generally constraints will
> modify SDP internally inside the webrtc platform.
Agreed.
> I don't even support to expose the low level API and
> implementation detail. For signalling purpose, we have to share some
> information, regarding capabilities, with the other peer. And this
> information should be exposed to the application.
That is not strictly true. Any immutable low-level property should
be hidden from the application developer. Meaning, as an application
developer I don't care that the signaling layer is using encryption key
"9823cuj980ru890e" and yet (I think) this shows up in the SDP. If I
don't ever need to know about it, I shouldn't have access to it.
The more I think about it, the more I am beginning to believe we
need to define two sets of APIs:
1. A low-level API for integrators
2. A high-level API for application developers (layered on top of the
low-level API)
And browser vendors would be expected to interact with the
signaling layer directly.
>
> Also from the video you specified ( gegarding this
> http://lcsd05.cs.tamu.edu/slides/keynote.pdf) slide 31, it is
> suggested to provide an Programmatic access to all data, even though,
> that is also available in the form of string. So the approach to
> implement the capabilities in the form of API seems to be good even
> according that video.
It's definitely moving in the right direction, but we can improve
further as mentioned above. I totally agree with you though, no one
should have to parse Strings manually unless they are interacting with
the signaling layer directly.
Gili
Received on Friday, 19 July 2013 15:41:51 UTC