Re: Expose capabilities / Allow for IP:Post based connections / Better abstraction

+1, maybe not the best API, but I have always criticed why is so
complicated to establish a DataChannel. On my polyfill, following the spec,
it didn't seems that you require candidate messages, and common sense say
it too. What info do you need to interchange after doing the offer/answer?
And also, the direct connection using IP:port using the STUN data would be
a good idea (using WebRTCSocket as you propose not).
El 08/07/2013 07:15, "Johannes Hange" <moooitic@mailbox.tu-berlin.de>
escribió:

>  Dear WebRTC,
>
> you are the future, and should be carefully build. The current proposal
> does not expose the capabilities gained very well.
>
> In general, the standard puts capabilities into a monolithic (pool) object
> (for the sake of performance and probably due to SIP influences). This may
> be due to a focus on video and audio in the initial development phase of
> the protocol, for which this setup is probably a good idea and common
> practice.It currently has the disadvantaged that the developer can't access
> and use the functionality separately, has to write complicated code for
> simple things and is restricted by predefined flows.
>
> - Objects should be independent from an API perspective:
>     - Resources (streams) should be pooled under the hood and have nothing
> to do with the API
>     - If necessary expose "pools" the developer can "add" to, not require
> them
> - Added protocols and gained features should be exposed to the developer
> (if there are use cases)
>     - So he can invent what to do with them
>     - Example below
> - Higher level objects are a good addition, but not a good base
> abstraction.
>     - Once you have a monolith, breaking it up in a lib is ugly, the other
> way around is not (Look at the code that exists today to do this ...)
>
> This was written under the assumption that much of the existing
> infrastructure is used and little adapted. I suggest a dual approach where
> small exposed objects and the current big monolith co-exist (lets see who
> wins in 2.0 by analyzing usage ...).
>
> From a data channel / web developer perspective the API and requirements
> are overly complicated and lack the abilities to:
>     1 - Establish a connection to another user directly, based on the
> exchange of ip:port pairs (not large SPD)
>         - [RTCPeerConnection.]connect(ip, port, [timeout], [number] ...)
>             - punches holes until [timeout], [number] may be useful to
> regulate the number of punches
>             - various security restrictions to address flooding /
> miss-use, but does not differ from current attack vectors
>         - onconnect / callback
>             - continue flow (exchange SDP)
>     2 - Find out the IP of the current system
>         - getIPAddresses(['stun: ...', 'stun: ....'], ...)
>             - Provide a call outside of the webrtc object
>     3 - Provide a simple WebRTCSocket alternative to send data
>         - WebRTCSocket("to_ip:to_port", "my_ip:my_port" /*obtained via
> navigator.getIPAddress(stunServers)*/)
>             - Which does the following (probably implemented more
> efficiently):
>                 - RTCPeerConnection.connect(to_ip, to_port);
>                 - createDataChannel
>                 - Expose events of the data channel
>         - This can be done for audio/video too in order to break up the
> monolithic nature ...
>
> Towards ICE:
>     - Build own Http flows and provide the ability to solve the problem
> without ICE:
>         - {'iceServers': [{'url': 'https://example.org/myip'}]};
>             - For most clients this will provide me a valid address for
> later hole punching and it's easy to create
>             - Return any answer format the developer chooses, client code
> knows what to do
>             - I can start signaling logic at this point already (and close
> my server to the public)
>         - Client must convert IP into a SPD format for exchange
>             - createOffer(ip, function(description) {....})
>
> Kind regards and thanks for reading
> Johannes H.
>
> PS: I am glad to answer anything unclear or address issues (participate in
> discussions)
>