Fwd: Re: Towards a new charter for the WebRTC Working Group

(I forgot to CC public-webrtc@w3.org, so I'm forwarding missing messages
of this thread for the sake of completeness.)


-------- Forwarded Message --------
Subject: Re: Towards a new charter for the WebRTC Working Group
Date: Fri, 12 Jan 2018 00:22:50 +0100
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Lennart Grahl <lennart.grahl@gmail.com>
CC: Lorenzo Miniero <lorenzo@meetecho.com>, T H Panton
<thp@westhawk.co.uk>, Peter Thatcher <pthatcher@google.com>, Michael
Tuexen <Michael.Tuexen@lurchi.franken.de>, Martin Thomson
<martin.thomson@gmail.com>, Dominique Hazael-Massieux <dom@w3.org>

On 11 January 2018 at 13:31, Lennart Grahl <lennart.grahl@gmail.com> wrote:
> It took me a while to see this, too but it clicked when I basically
> ported a lot of code from RAWRTC to Firefox. I'd be happy to pull out
> RAWRTC's data channel implementation and make it possible to use this
> outside of RAWRTC itself. RAWRTC is a good candidate for this as it has
> very few dependencies. I guess this would be particularly interesting
> for smaller projects that want data channels such as janus-gateway.
> Please reach out to me if you're interested.

Is it C/C++ and does not assume multi-threading?
For example, I cannot use usrsctplib uses different threads, mandating
the app that integrates it to also be multiple threads. So I cannot
use it.
A good C library should not run a separate thread by itself to just
run a timer. Instead, provide a mechanism to tell the app when to pull
data from the lib (even openssl allows that).

Also, does your lib manage UDP/TCP ports by itself? or does it expose
a proper I/O API + events? I don't want/need a datachannel library
that manages ports, ICE or even DTLS. I already do that so just need a
layer on top of what I've already that.

I consider the state of the art of DataChannel absolutely rancid.





-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Saturday, 13 January 2018 13:48:23 UTC