Re: a new API proposal

Well, I only know WebRTC from a Javascript point of view and don't know too
much about the internal technology except what has been talked here, so I
think is obvious... :-D I know it's possible to develop partial if not
fully all my proposals in Javascript (I was doing it mentally just as a
mind game with the idea to show a prototype just when I received youe
email), only that I find fairly absurd to develop a state-less API like
mine over a stateful API like WebRTC Offee/Answer over a state-less API
like browser internals... and the same happens to don't require SDP over an
API that require them. I know it's mostly doable on Javascript, but I think
it makes more sense and would have some improved performance done at a
lower level.
El 01/08/2013 01:02, "Roman Shpount" <roman@telurix.com> escribió:

> My first and most obvious question is: Would it be sufficient if the
> described functionality were implemented as a JavaScript library? Most of
> what you describe is implementable this way even with the current
> specification, so why should anybody design a browser API specifically for
> this?
> _____________
> Roman Shpount
>
>
> On Wed, Jul 31, 2013 at 6:44 PM, piranna@gmail.com <piranna@gmail.com>wrote:
>
>> Due to my work I have need to read the last days the current WebRTC
>> specification. As you would know, I have been interested and focused
>> the last months only on DataChannels and I was very critic and upset
>> about how much work was needed to create a simple DataChannel between
>> two browsers (SDP, offer/answer, candidates...), but know that I have
>> read about how media streams are suposed to be used, now I can say
>> that the WebRTC is fairly overcomplicated.
>>
>> So, I have asked myself, now that I know how it works, how I would do
>> it? And I've got some conclusions that I think would be easy to be
>> integrated and I hope you find interesting enought to be debated.
>> Please don't take in account if there are some errors and only take in
>> account the proposed concepts.
>>
>> First of all, have on PeerConnection object an "autosignal" option.
>> When disabled, PeerConnection would require an external signaling
>> channel as is currently done, but if enabled, then an internal channel
>> is created between both peers as soon as possible and since then all
>> the signaling messages between both peers are transfered automaticaly
>> and transparent to the developer using this channel. Or explained
>> using current WebRTC concepts: if this autosignal option is enabled,
>> then the offer and the answer would return only the minimal data to
>> allow to create the connection between both peers and an internal
>> communications channel (a hidden DataChannel or just a plain socket,
>> but it doesn't matter if it's bandwidth reduced), and after that this
>> channel is used to transfer the subsequent candidates and do the
>> renegotiation between both peers: add and remove streams, change
>> resolution and quality, mute... As I said, this channel is purposed to
>> be internal and hidden, but it would be discussed to allow to use it
>> with send() / onmessage so it would not be required by the
>> applications to create dedicated DataChannels for
>> application-dependent purposes if latency or high-bandwidth are not
>> required (instant messaging, user interaction events...).
>>
>> Second thing, having reduced so much the required data to be
>> interchanged between both peers to create the communication since all
>> the data synchronization is done using the internal signaling channel,
>> reduce it to the bare minimum. As far as I know, with this method it
>> would be only required the STUN/TURN data so it's possible to know on
>> what port is listening each peer, and this data would be given by the
>> API as just an array with an object for each NAT and proxy that it's
>> needed to be transpased with their IP/domain, port, authentication...
>> This is a fairly basic data that can be serialized and transfer in
>> several ways, being this JSON or SDP or any other.
>>
>> Finally, also the multiconference problem showed the last days can
>> also being fixed this way, since several peers would connect to the
>> same internal signaling channel and sending and receiving messages as
>> a pool, or several signaling channels would be created, one for each
>> peer.
>>
>> With this both things, we have fixed the problems regarding with the
>> offer/answer mechanism and removed the requeriment to use SDP while
>> still being able to generate it to be compatible with legacy systems
>> requiring it, and also we fixed the problems regarding to adding or
>> removing streams or when the quality changes, because this can be
>> notified sending messages over the internal signaling channel.
>>
>> That's all for now, please send me any comment or suggestion you have
>> regarding this suggestions.
>>
>> Greetings, Jesús Leganés Combarro "piranna".
>>
>>
>>
>>
>> --
>> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
>> monton de sitios diferentes, simplemente escribe un sistema operativo
>> Unix."
>> – Linus Tordvals, creador del sistema operativo Linux
>>
>>
>