Re: Alternative data API

On 01/26/2012 02:59 PM, Harald Alvestrand wrote:
> 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):

Yes, I did list the use-cases but not the requirements, mainly because I 
could not really go from the use cases and derive (many of) the 
requirements. The ones below, possibly with the exception of Req. 2, are 
among those that I could not really derive from the 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 agree. I think 2 and 4 are very straightforward to fulfill, and 1 
needing some more work - but then again there has been little evidence 
of the need, and my input was more on offering a "do less now, add 
things if there is need" approach.

>
> 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.

Why? I can't see that that the fact that there are 
single-channel-assuming applications deployed would stop adding e.g. 
multiple-channel support later (as long as the single-channel API 
continues to work) if there are use cases demanding that.

Again, I'm fine with doing the more advanced approach, my input was 
mostly to show that there is an alternative approach available that is 
simpler (it may for example allow us to define fewer new events - 
something that is not introduced everyday), is better aligned to 
existing messaging APIs _but_ less capable.

It is up to the group, and as contributor I will do my best to make the 
selected approach as good as possible (there may on the other hand be 
very little value in that...)!

>
>                     Harald
>

Received on Thursday, 26 January 2012 14:41:36 UTC