Re: JavaScript API on top of SDP

On Wed, Jul 17, 2013 at 12:05 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  Hi Eric,
>
>     I assume you are referring to
> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-11
>
>     I see the following problems with this document:
>
>    1. Section 4 states: "It is assumed that the user applications are
>    executed on a browser". This assertion flies in the face of many of our
>    use-cases.
>     2. Without API examples, there is no feedback mechanism of how
>    good/bad the API fits our use-cases. Recent conversations highlight why
>    need such a mechanism.
>    3. The document fails to explain the reasoning behind the design
>    decisions that were made.
>
>     Don't get me wrong: this is a good start. But this document is to a
> Design Document what voting is to Democracy. It is just the tip of the
> iceberg. We can, and should, do a lot more.
>

Send text.

-Ekr


>  Gili
>
> On 16/07/2013 1:42 AM, Eric Rescorla wrote:
>
> 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
>>
>>
>>
>>
>>
>
>