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

Re: Moving forward with SDP control

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Fri, 19 Jul 2013 18:02:13 -0400
Message-ID: <51E9B765.40909@bbs.darktech.org>
To: Peter Thatcher <pthatcher@google.com>
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 19/07/2013 5:53 PM, Peter Thatcher wrote:
> On Fri, Jul 19, 2013 at 2:48 PM, cowwoc <cowwoc@bbs.darktech.org 
> <mailto: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.

Received on Friday, 19 July 2013 22:02:59 UTC

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