Re: [rtcweb] Data Channel Negotiation and reopening of decisions

On 2013-02-19 00:25, Paul Kyzivat wrote:
> On 2/18/13 6:45 AM, Tim Panton wrote:
>>
>> On 15 Feb 2013, at 21:15, Martin Thomson wrote:
>>
>>> On 15 February 2013 12:55, Michael Tuexen
>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>> I think I understand what you are proposing. But what happens, if
>>>> both sides at about the same time open want to open a data channel.
>>>> For both sides outgoing stream X is free, so they use this. So the
>>>> endpoints end up with one data channel instead of two.
>>>
>>> Actually, I'd go further than that.  I'd require that browser
>>> implement the same algorithm for selecting the stream to use.  That
>>> implies that in all cases other than the rarest race conditions, you
>>> get the same data channel.
>>
>> I'd remind everyone that in the case of the data-channel there are _no_
>> cases where the endpoints don't know what the other end is supposed to
>> be doing.
>>
>> There are no statically programmed legacy devices which support the
>> data channel.
>>
>> Endpoints can be assumed to be dynamic javascript clients programmed
>> to interoperate with each other,
>> most often with the same javascript loaded from the same source and
>> sharing a signalling channel.
>
> I disagree.
>
> For the cases RTCWEB cares about, presumably at last one end is a
> javascript client. But the other end may not be. There can be many cases
> where one end is a server.

The normal way for a web application to communicate with a server is 
using http. Recently, more optimized means have been defined, WebSocket 
and Server-Sent Events.

Of course you could terminate a rtcweb data channel in a server, but I'm 
not sure how much that really buys you over using WebSockets in practice 
(sure, WebSockets only support reliable delivery, so perhaps for low 
latency needs there could be a gain).

But that said, why couldn't the server do the same things the client 
would do in JS over the currently defined data channel if you really 
want to use the rtcweb data channel for client-server communication?

>
> The case *I* care about right now is where one end is a CLUE server, and
> the other end is an RTCWEB browser client. CLUE needs a data channel,
> and we are aiming at one compatible with RTCWEB, in part precisely to
> make this case a possibility. And while RTCWEB doesn't care, CLUE wants
> to be able to use the same channel machinery with *neither* end is a
> browser.
>
> Obviously this doesn't exist yet, so we are flexible about the details.
> But we need for it not to depend on being javascript to javascript.
>
>      Thanks,
>      Paul
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb