W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

The best API possible (Was: Teleco Integrators vs Web Developers vs Browser Implementers)

From: Emil Ivov <emcho@jitsi.org>
Date: Sat, 06 Jul 2013 00:25:48 +0200
Message-ID: <51D747EC.7050204@jitsi.org>
To: "piranna@gmail.com" <piranna@gmail.com>
CC: cowwoc <cowwoc@bbs.darktech.org>, Martin Steinmann <martin@ezuce.com>, tim panton <thp@westhawk.co.uk>, Yana Stamcheva <yana@jitsi.org>, Parthasarathi R <partha@parthasarathi.co.in>, Christer Holmberg <christer.holmberg@ericsson.com>, Iņaki Baz Castillo <ibc@aliax.net>, Robin Raymond <robin@hookflash.com>, Roman Shpount <roman@telurix.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, Ted Hardie <ted.ietf@gmail.com>, "public-webrtc_w3.org" <public-webrtc@w3.org>, Eric Rescorla <ekr@rtfm.com>, Martin Thomson <martin.thomson@gmail.com>
On 05.07.13, 23:54, piranna@gmail.com wrote:
>> We should be building the best API possible
> +1

This has already been mentioned in a couple of places and I feel there's 
a certain amount of confusion on the subject.

While I am not an SDP fan (who is?) and while I think that it should 
(and will) eventually go, I still think it would be helpful for everyone 
to know exactly what they are wishing for:

* Removing SDP and Offer/Answer from WebRTC is NOT going to produce an 
API that's simpler for the regular web developer *

On the contrary. It would mean that all the things SDP is currently 
taking care of would have to be understood and managed by the JS: key 
negotiation for SRTP, encoding ICE priorities, ICE foundations and 
options, RTP payload types, codec parameters, negotiating supported 
formats, renegotiating them ... All this will need to be handled by the JS.

Again, I am not saying this is wrong, I am not denying the fact that it 
will give a lot more flexibility when implementing specific signalling 

However, all those who hope that such a new API would be easier for a 
web developer to use, should realise that they are going to get exactly 
the opposite.

Of course, one could expect a variety of JS stacks to appear and 
simplify the API for specific use cases. Web developers would then be 
able to use those and their lives would eventually be easier. Still, 
that's not going to happen overnight and until it does, you will be 
needing a substantial amount of RTC knowledge in order to build WebRTC 

I assume that's part of the reason while a number of people have 
suggested finishing the current API as 1.0 and then going down the path 
of a lower-level API for 2.0.


Received on Friday, 5 July 2013 22:26:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC