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

>-----Original Message-----
>From: Emil Ivov [mailto:emcho@jitsi.org] 
>Sent: Friday, July 05, 2013 6:26 PM
>To: piranna@gmail.com
>Cc: cowwoc; Martin Steinmann; tim panton; Yana Stamcheva; Parthasarathi R;
Christer Holmberg; Iņaki Baz Castillo; Robin Raymond; Roman Shpount; Adam
>Bergkvist; Ted Hardie; public-webrtc_w3.org; Eric Rescorla; Martin Thomson
>Subject: The best API possible (Was: Teleco Integrators vs Web Developers
vs Browser Implementers)
>
>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
protocols.
>
>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 applications.
>
>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.
>
>Emil

+1
This is the post, in my view, that makes the most sense from the entire
firestorm of messages.  Doing a standard requires a measured approach and
there is no such thing as the 'Perfect API'; that is entirely subjective.
However, finishing what we started has a lot of merit.  Likely most of you
use Agile and the process of continuous improvement.  This would give all of
us the opportunity to get going with something instead of waiting forever
for the perfect solution that never comes.  P2P will be important but if
WebRTC does not easily work with the existing world it will turn into a
niche protocol before it even gets off the ground.  WebRTC is the
opportunity to get some of the great user experience created by proprietary
consumer solutions into the enterprise in a standards based way and without
interop with standard SIP/XMPP this opportunity is squandered.  Emil
articulated it very well:  The complexity remains and if the API gets really
simple you have to deal with it elsewhere and I can tell you from experience
that Web developers are way over their head doing it.
--martin
www.sipfoundry.org

Received on Saturday, 6 July 2013 06:47:58 UTC