Re: Alternative data API

On 01/26/2012 12:41 PM, Stefan Hakansson LK wrote:
> (Strictly in a contributor role):
>
> I've written up this text on how the data API could look if we stayed 
> with the model of the August 23rd version of the webrtc spec 
> (<http://dev.w3.org/2011/webrtc/editor/webrtc-20110823.html>) where 
> the data API was directly on the PeerConnection object ("send" method).
>
> It is much less advanced than what Justin has proposed, the main 
> advantages are Web Socket alignment (but I think Justin is aligning 
> the DataStream's to WS right now) and less work to specify as much can 
> be inherited from Web Sockets. I don't know how much of the Web Socket 
> implementation that could be re-used.
>
> I attach some text that could be part of the webrtc rec.
>
> I don't have a strong view on what direction to take, all I want to do 
> is to point out that this approach could be selected if we want to 
> minimize work now (and possibly extend later if there is demand); the 
> drawback is less functionality (at least from day one).
Strictly as a contributor, too:

I believe this fails on one of the listed requirements in draft-jesup (I 
note that you listed the use cases, but did not include the requirements 
that Randell inferred from these use cases):

    Req. 1  Multiple simultaneous datagram streams must be supported.

There is also no support for:

    Req. 2  Both reliable and unreliable datagram streams must be
       supported.

   Req. 4  The application should be able to provide guidance as to the
       relative priority of each datagram stream relative to each other,
       and relative to the media streams.

While these COULD be done with the suggestion of "add options" under 
"future extensions", I think this seems like a clear and present 
requirement.

A number of the other requirements aren't really relevant to the API, 
being more protocol related, but these 3 seem to be impossible to 
satisfy without corresponding API functionality.

I believe embedding a single-channel data function into PeerConnection 
(and therefore encouraging the deployment of single-channel-assuming 
applications) would make it harder to satisfy this requirement set later.

                   Harald

Received on Thursday, 26 January 2012 13:59:58 UTC