Re: Data API: what is agreed, what is open

On 2/8/2012 4:42 AM, Stefan Hakansson LK wrote:
> As contributor:

>> Open
>> ====
>> * Should the API be uni- or bi-directional?
>
> I have a slight preference for bi-directional beacuse
> a) It makes speccing the API a bit simpler since we need to specify only
> one object type ("dataSocket" or something like that) that can send
> ("send") and receive ("onmessage") rather than two different objects
> (one "dataSendPort" and one "dataReceivePort")
> b) Better aligned to WS - easier for the web app developer to grasp
> c) I expect many applications to exchange data rather than it going one
> way - so it would be natural
> d) If the app developer wants uni-directional messaging it is simple to
> use a bi-directional channel in one direction only (and set up another
> for the back channel)
> (but bi-directional is not something I will fight for - it is more a
> matter of taste)

I also don't have a strong preference if the implementation is similar 
in complexity.  Originally my preference for Unidirectional was based on 
(largely) having to handle glare in bidirectional.

This also brings up again how channels are identified, which I realize 
I'd glossed over in my last few posts.

The options are:

1) by SCTP stream id
This is very intuitive and leaves all the semantics about what a channel 
means in context to the application.  It requires however that opening a 
data channel specify a stream id.  They could be unidirectional, or 
bidirectional if we deal with glare (by merging the two opens, which 
should be simple).  It is more of a 'network' type of interface than a 
'js' type of interface.

2) by some form of abstract textual label chosen by the app
Also fairly intuitive, but complicates bidirectional glare handling and 
incoming data handling slightly.  We'd need to use either signaling/JSEP 
(no, thank you) or use create-time metadata packets (PPID or use a 
reserved stream (0)).  Unidirectional is straightforward; bi-directional 
would handle glare by melding the two separately-chosen streams (similar 
to 1's handling of glare, but searching all "in-open" state streams for 
a match).  You can't just choose a 'winner' of glare and both use that 
stream because the stream may already be in use as part of the startup 
of a different channel.

So in 2), the stream IDs of the two sides aren't truly correlated though 
they'll usually be identical in practice, so we'll need to keep track of 
both for demuxing incoming data to the correct dataChannel object.  No 
big deal really, just another array of size [# of streams].

I was leaning towards 1, but I'm starting to think 2 is more in keeping 
with the idioms of JS programmers and other HTML5 interfaces. 
(Experts?)  Either is no big problem to implement I think, unless I 
missed something.

The only way I can see it being a compatibility issue is if someone 
wanted to gateway existing SCTP protocols into WebRTC, since existing 
protocols use fixed stream values - and then you could just use the 
stream number as a label (ugh).  And I see no use-cases where this is 
important.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Wednesday, 8 February 2012 17:04:07 UTC