Re: JavaScript API on top of SDP

On Mon, Jul 15, 2013 at 10:06 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

> We could add an object-oriented API that defined a javascript structure
> representing the SDP.  Developers could modify the structure using
> JavaScript, rather than having to parse it themselves.  Given such a JS
> structure, it would be easy to serialize it as JSON, so developers wouldn't
>  need to touch the SDP directly.  But they would still have the option to
> do so, if they wanted to do something that the API didn't cover (and it
> would be up to us to decide how much the API covered.)
>
> - Jim
>
>
I think this API would be of very little use at best. The issue is that SDP
in WebRTC is under-defined. Unless it is clearly specified what SDP
features are supported, which portions of SDP can be modified and what
these modifications mean, SDP does not present a valid API surface. It is
possible to parse SDP and serialize it back from JavaScript. If you take a
look at almost every WebRTC JavaScript library created so far, you would
see that  practically each of them parses SDP. The problem is that SDP
produced by the browser can change in a way that will render any code that
relies on SDP data unoperational. For example, adding bundle will almost
guarantee to break all current JavaScript code that deals with parsed SDP.
Not the SDP parser, which will continue to work, but interpretation of this
parsed data will no longer work and will need to be updated. Unless the
meaning of each attribute and supported attribute values in SDP are defined
somewhere, giving me a list of parsed attributes does not help me in any
way.

So, unless you are planning to propose an API that replaces SDP with a
JavaScript object with a well defined set of methods, and by doing so
clearly specify supported media description functionality, this new API
will not help in any meaningful way. Furthermore, unless supported SDP is
clearly defined or replaced by well defined API this specification could
never become a complete standard.
_____________
Roman Shpount

Received on Monday, 15 July 2013 15:59:13 UTC