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

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

From: <piranna@gmail.com>
Date: Sat, 6 Jul 2013 00:42:41 +0200
Message-ID: <CAKfGGh1_NygQJoevQ0dKfU0wuyBnpRmcPB0tEoNWRFzgxgpxEA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Emil Ivov <emcho@jitsi.org>, 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>
Ideally to me (maybe utopic?) I would only need to set an
ID/token/IP:port/whatever on one end and a config object defining how
I want the connection, and don't need to worry anymore, just get an
event when my previous connection request have been done, or when a
new one is being received, no more. I don't know if the ones that
propose to remove Offer/Answer are talking about doing this way, but
it's my interpretation about how would be the solution.

Disclaimer: I'm designing my WebP2P.io library
(github.com/ShareIt-project/WebP2P.io) just this way so you can
inspect it, but I'm doing it this way just because I think is the
easier API could be done IMHO...

2013/7/6 Martin Thomson <martin.thomson@gmail.com>:
> On 5 July 2013 15:25, Emil Ivov <emcho@jitsi.org> wrote:
>> 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, this isn't necessarily true either.  A good API can do most of
> this stuff for you.  There is obviously a responsibility on the JS
> application for carrying some of this information, but that's a long
> way from having to deal with ICE foundations.
>
> A really good API would do two things: make it easy to do the easy
> things, and make it possible to do some really interesting things.  A
> really good API can be both low- and high-level at the same time.
>
> If you haven't read CU-RTC-Web, I recommend that you do.  It's not
> really good, but I think that you'll find that it is possible to do
> the easy things really easily, without compromising access to the
> internal stuff.



-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux
Received on Friday, 5 July 2013 22:43:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:34 UTC