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

Re: Moving forward with SDP control

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 19 Jul 2013 15:10:38 -0700
Message-ID: <CAJrXDUE_Gf7+zTov+ADOBE02moKV-zMa3S+dO_CxDd1aXk7MQQ@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: Jesús Leganés Combarro <piranna@gmail.com>, Kiran Kumar <g.kiranreddy4u@gmail.com>, Likepeng <likepeng@huawei.com>, Cullen Jennings <fluffy@iii.ca>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
On Fri, Jul 19, 2013 at 3:02 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  On 19/07/2013 5:53 PM, Peter Thatcher wrote:
> On Fri, Jul 19, 2013 at 2:48 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>     That doesn't matter. Think of OOP "encapsulation". The API defines a
>> contract. It is well within its right to declare SDP as an undefined/opaque
>> token outside the scope of the API. Anyone who relies upon its contents is
>> relying on implementation details that will change over time and break
>> their application. They have no one to blame but themselves.
>  Perhaps that could be true if this were purely WebRTC
> browser-to-browser, but it's not.  The SDP put into the
> setRemoteDescription can come from anywhere, not just another WebRTC
> browser.  For example, it could come from a legacy device, a mobile app, a
> gateway server, or an application server written by the same developer
> writing the JS.  And at that point, how much does it matter if the SDP came
> from a server written by the developer or JS written by the developer?
>     It matters because you're mixing two different API levels.
>     The high-level API doesn't specify the SDP contents. This is what Web
> Developers use.
>     The low-level API specifies SDP or whatever signaling format we end up
> using.
>     Most Web Developers will never need to see/use the low-level API and
> we spare them a lot of grief. Anyone who needs access to these internals
> can still do so, using the low-level API.
>     As a side-note, this has the added benefit of allowing you to layer
> different high-level APIs on top of the low-level API. If the low-level API
> is written in C, then you can have a JS high-level API for browsers and a
> Java high-level API for Android, an Objective-C high-level API for iOS, and
> so on.
>     If you stuff these two layers into a single API you will have to
> re-implement it the low-level when all you really want to do is publish a
> new high-level one.
I'm completely in favor of a good lower-level API with the possibility of
different higher-level APIs built on top in JS.  And perhaps it even makes
sense to have a higher-level baked into the browser as well.  I'm hoping
that 2.0 goes in the direction of "good low-level API that higher-level
APIs can build on", and we can go from there.

> Gili
Received on Friday, 19 July 2013 22:11:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC