Re: Minimizing the protocol (Re: Data API)

I think we are going about this the wrong way. Lets sort out how labels work with media tracks then ask why if data channels would be any different. I think that this is going to turn out to be a non issue. 


On Feb 28, 2012, at 4:28 PM, Randell Jesup wrote:

> On 2/28/2012 4:18 PM, Harald Alvestrand wrote:
>> On 02/28/2012 06:36 PM, Randell Jesup wrote:
> [SNIP]
>>> Sorry.
>> 
>> argh. was fun while it lasted :-)
>> second suggestion is to have the first message contain the label and
>> flags.....
> 
> Yup.  My rough plan was:
> 
> First message on a stream (or first after a reset of the stream):
> (pseudo-structure)
> {
>    CHANNEL_OPEN,
>    flags, // reliable, unreliable, out-of-order, partially-reliable (and type), etc
>    pr_value,  // partially-reliable
>    DOMString label,
> }
> 
> and response:
> {
>    CHANNEL_OPENED,
>    forward_stream_id, // optional
> }
> 
> This assumes we can avoid stream number glare by using an even/odd differentiation.  If we can't or don't want to, we can include in the response the forward channel it's responding to (it would come in on the reverse channel for that bidirectional pair).  This allows us to avoid stream ID glare by never requiring the bidirectional pair have the same stream number.
> 
> -- 
> Randell Jesup
> randell-ietf@jesup.org
> 

Received on Wednesday, 29 February 2012 21:14:51 UTC