Re: Moving forward with SDP control

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
>