On Fri, Jul 19, 2013 at 1:25 PM, Adam Roach <adam@nostrum.com> wrote: > I can't +1 this hard enough. I certainly don't want every javascript > application that makes use of the WebRTC API to independently discover that > mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to unusable > if you try to send it more than 320x200 video, and then try to solve that > problem. > > Again and again, for every permutation of phone and operating system > version. > > Yeah, someone has to do this kind of characterization, and some of it can > be done real-time if you're interacting directly with the operating system. > So... maybe we could add yet another API to WebRTC to allow applications to > build this functionality themselves rather than counting on them > characterizing the systems they care about and blowing up on the ones they > don't. > > But, honestly, any course of action that relegates this to the > applications seems to have the dual properties of forcing it to be > implemented hundreds of thousands of times while making the actual user > experience worse. > You cannot be more wrong. Each application deals with predictable set of scenarios (ones it produces) and interfaces with predictable set of non webrtc devices. These external devices are under control of the application developer. Application developer is responsible for interop with these devices. What is needed is predictable media and signaling generated by webrtc devices running the same application. With negotiation and SDP backed into the webrtc device it is very hard to achieve. So, for me as webrtc developer let me develop a negotiation scheme that works for me and make sure it stay working regardless of the browser type or version. Right now controlling webrtc application feels like driving the boat down the river by tickling the captain. _____________ Roman Shpount
Received on Friday, 19 July 2013 17:38:06 UTC