- From: Rob Manson <roBman@mob-labs.com>
- Date: Mon, 22 Jul 2013 18:37:35 +1000
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
On the topic of the gdocs survey that Peter T setup...for my feedback I've tried to use little more positive language e.g. not "strongly dislike" - but instead "strongly like a change" 8) I'm actually really impressed with and enthusiastic about what has been achieved for WebRTC so far. Yet I also think there's a compelling case for making a change now before 1.0 is finalised that will make WebRTC significantly better (less fragile and more extensible). I think the issues laid out in http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00 are very clear and well thought out. Also, in the gdocs survey I think the "OK/Good for simple things" question is a bit misleading. Firstly, "OK" and "Good" really are two separate things. Secondly, this initially led me to think about just a basic video call and I answered "yes". But when you think about "mute" or "on hold", etc. which are pretty simple things too then the answer clearly has to be no. I also think how this all relates to the whole RTCDataChannel model is important. Both for channel setup and for the ability to use RTCDataChannels for signaling and how that relates to both SDP and O/A. Just a few thoughts. roBman On 21/07/13 17:51, Stefan Håkansson LK wrote: > On 7/21/13 8:28 AM, Rob Manson wrote: >> Thanks Stefan. >> >> Yep...will do. > > I can see your input now, thanks! > >> >> roBman >> >> >> On 21/07/13 15:46, Stefan Håkansson LK wrote: >>> Rob, >>> >>> Peter T has a spreadsheet at >>> https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=1 >>> collecting the experiences made when using the WebRTC APIs. Could you >>> enter what you have learned? The more people that contribute the better. >>> >>> Stefan >>> >>> On 7/21/13 1:08 AM, Rob Manson wrote: >>>> +1 >>>> >>>> As a web developer that's spent a lot of time experimenting with the >>>> currently specified version of the WebRTC related APIs and that's been >>>> following the mailing list debates closely this really does seem like >>>> the best resolution. >>>> >>>> It provides a more extensible and flexible architecture that can evolve >>>> at "web developer speed" not "aligned browser release speed". And at >>>> this speed it will also be less fragile. >>>> >>>> It provides a clear separation of concerns so people can use SDP where >>>> they want, but not everyone is restricted by the timelines of other WGs >>>> that are required to evolve SDP. >>>> >>>> And it would enable even more experimentation and future facing >>>> development too. >>>> >>>> >>>> Also, in terms of timing I think getting this right is more important >>>> than the current commitment to a deadline. >>>> >>>> This is from the perspective of a web developer that has gone to all the >>>> effort of just finishing a book on "Getting started with WebRTC" using >>>> the existing API and who is also working on several commercial projects >>>> based on the current API. >>>> >>>> So if anyone should be promoting "just get the first version out" then >>>> it should be someone in my position. But I think you really will find >>>> that most web developers would rather we got this abstraction right >>>> first so we can avoid all of the extra support issues and application >>>> re-work that will be required down the track if we don't. >>>> >>>> roBman >>>> >>>> >>>> On 20/07/13 23:51, Iñaki Baz Castillo wrote: >>>>> Let W3C experts to define a good JS API for WebRTC (with no SDP), let >>>>> MMUSIC WG to define a SDP format for WebRTC, and then let JavaScript SIP >>>>> experts to build JS libraries on top of it to play the SDP game, and we >>>>> all will be happy. And telcos will be much more happy than they think. >>>>> Let's get rid of all the SDP O/A stuff in the browser. The browser is >>>>> not a phone and "fixed logic + fixed code" does not work here. >>>> >>>> >>>> >>>> >>> >>> >> >> > >
Received on Monday, 22 July 2013 08:38:07 UTC