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.
Gili
Received on Friday, 19 July 2013 22:02:59 UTC