- From: <piranna@gmail.com>
- Date: Sat, 6 Jul 2013 00:42:41 +0200
- 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