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

Re: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

From: Rob Manson <roBman@mob-labs.com>
Date: Tue, 23 Jul 2013 07:57:28 +1000
Message-ID: <51EDAAC8.3090405@mob-labs.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Fair enough...life is full of compromise 8)

roBman


On 23/07/13 01:04, Peter Thatcher wrote:
>
>
>
> On Mon, Jul 22, 2013 at 1:37 AM, Rob Manson <roBman@mob-labs.com
> <mailto:roBman@mob-labs.com>> wrote:
>
>     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
>     <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.
>
>
> Yes, I originally had two separate buckets, but that ended up with too
> many buckets, so I merged them.  Basically, I found that distilling all
> that feedback into a readable summary was hard :).   Some precision was
> lost in the simplification.
>
>
>     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=__0AuaKXw3SkHMSdHlZdV9RN0xSWFhyb__Vl4anJLRkVPV0E#gid=1
>                 <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 21:57:55 UTC

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