Re: JavaScript API on top of SDP

There already is a use-cases document in IETF.

I don't think it really needs to come with API examples for each
use case, though perhaps it would be useful for some of the less
obvious ones.

-Ekr


On Mon, Jul 15, 2013 at 11:21 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  Hi Jim,
>
>     Over a month ago, I proposed publishing a design document in which you
> would list all use-cases and how the API will address it (insert a brief
> note as a place-holder, replace with formal API when it becomes available).
> This document would be useful at this point, as it would acknowledge that
> you are aware of the use-cases and let us how you plan to address it.
>
>     Is the WG willing to publish such a document?
>
> Thanks,
> Gili
>
>
> On 15/07/2013 2:05 PM, Jim Barnett wrote:
>
>  I think that the group has always known/assumed that we would need to
> specify what SDP features are supported, what can be modified, etc.  Maybe
> I’ve missed something, but I haven’t heard anyone say that this wasn’t
> necessary.   It’s just that we haven’t gotten around to it yet.  ****
>
> ** **
>
> -          Jim****
>
> ** **
>
> *From:* Roman Shpount [mailto:roman@telurix.com <roman@telurix.com>]
> *Sent:* Monday, July 15, 2013 11:59 AM
> *To:* Jim Barnett
> *Cc:* public-webrtc@w3.org
> *Subject:* 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****
>
>  ****
>
>
>