Sent from my iPhone
On Jul 3, 2013, at 12:08 AM, "piranna@gmail.com<mailto:piranna@gmail.com>" <piranna@gmail.com<mailto:piranna@gmail.com>> wrote:
> Imagine you design a website in which user-A must be able to send an
> integer, a float and a string to user-B. Of course the "signaling"
> would use HTTP or WebSocket. How would you do that? I can imagine 1000
> ways. Why should I use a fixed blob string?
>
Totally agree. What would be the best option, that PeerConnection show a JS object with the fundamental connection data so it could be serialized on diferent ways (SDP too)? Could it worth to develop a SDP parser in javascript to start defining this object format, or is it better to just show PeerConnection internal structures?
I am not supporting one against other . I personally feel the more API points one provides the more the chances of doing things wrong by a web developer who is not a Media stack, codec configuration, security parameters and RTP parameters expert.
These are already complex and exposing peer connection with these details, might not be right either.
The current API might not be complete but can be extended minimally ( as standards evolve ) to support most of the usecases. I still think that modifying SDP by hand might not be needed for majority of the use cases. This implies we have to wait for standards to get settled on the SDP usage, add just enough extensions to the current API and constraints scheme to meet various flavors of the usecases
Thanks
Suhas