Re: Summary of "What is missing for building real services" thread

Another I miss in the current specification is the inexistence of an
in-wire signaling channel, meaning that if you add a stream or a
DataChannel after the connection is established, due to how it's done the
specification currently you need to go back to do the Offer/Answer dance
and to use a external signaling channel or implement youself an in-wire
signaling channel to do it, while the two PeerConnection objects are
interconnected between them and the Offer/Answer dance it's an internal
feature.

Send from my Samsung Galaxy Note II
El 18/01/2014 01:10, "Justin Uberti" <juberti@google.com> escribió:

> We maintain native API bindings for PeerConnection for Android (Java) and
> iOS (ObjC). They sits atop a C++ PeerConnection implementation (which also
> powers the JS impl in Chrome), and all mirror the W3C API fairly well. Is
> this not sufficient?
>
>
> On Fri, Jan 17, 2014 at 11:11 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>
>> Iñaki,
>>
>> I don't know why you seem to feel so threatened by this proposal. I'm
>> simply highlighting the fact that authors of native WebRTC applications and
>> headless servers have a need for such a library. Whether I personally work
>> on it or not does not invalidate that point. I'm bringing it to the
>> community's attention and we'll see where it goes from here. If nothing
>> happens, so be it, but at least interested parties see that they're not
>> alone. We are in a better place to collaborate with each other once we see
>> who else is interested.
>>
>> Gili
>>
>>
>> On 17/01/2014 12:56 PM, Iñaki Baz Castillo wrote:
>>
>>> Ok, do it.
>>>
>>> 2014/1/17 cowwoc <cowwoc@bbs.darktech.org>:
>>>
>>>> On 17/01/2014 12:42 PM, Iñaki Baz Castillo wrote:
>>>>
>>>>> 2014/1/17 cowwoc <cowwoc@bbs.darktech.org>:
>>>>>
>>>>>> That's not what I'm talking about or asking for.
>>>>>>
>>>>>> I'm not talking about "one library to rule all" but rather a reference
>>>>>> implementation by one of the vendors (I used Google as an example
>>>>>> because
>>>>>> their implementation is already up on webrtc.org). Nothing would
>>>>>> prevent
>>>>>> others from coming up with alternate libraries, or forking Google's.
>>>>>>
>>>>>> I'm just saying that we should have *at least one* Native API that
>>>>>> mirrors
>>>>>> the Javascript API.
>>>>>>
>>>>> No. We need specifications and standards. And if there is interest
>>>>> then smart guys will develop libraries/stacks based on those
>>>>> specifications (in different programming languages) by providing the
>>>>> API they want (because I'm very sure you have never requested to
>>>>> Asterisk and FreeSwitch, or Apache and Nginx, that they must offer the
>>>>> same API).
>>>>>
>>>>
>>>> I'm saying the specification must lock down the JS API, and in parallel
>>>> the
>>>> Native API should try to mirror the capabilities of the JS API but that
>>>> is
>>>> an asynchronous process outside the scope of the specification.
>>>>
>>>> To reiterate: the point of this API is *not* code portability but
>>>> rather a
>>>> baseline or proof of concept showing *one way* to implement each one of
>>>> the
>>>> features. Meaning: I am not asking all vendors to use the same API
>>>> design,
>>>> but I am saying we should put out a *reference implementation* that
>>>> shows
>>>> them an example of how it can be done.
>>>>
>>>>
>>>>  But you cannot tell to a W3C or IETF group that "we need a reference
>>>>> implementation". If the specs are good then you DO NOT need to learn
>>>>> from the code of others, nor to copy it.
>>>>>
>>>>
>>>> Not true. Regardless of how good the spec is, it takes a non-trivial
>>>> amount
>>>> of time/effort to implement the spec from the ground up and most of
>>>> pieces
>>>> are not interesting from an innovation point of view. We should be able
>>>> to
>>>> reuse code from the reference implementation (avoid reinventing the
>>>> wheel)
>>>> for components that we don't care about, and focus our
>>>> innovation/effort on
>>>> components *we do* care about. Right now it's an all-or-nothing thing,
>>>> which
>>>> is a waste of the community's time.
>>>>
>>>>
>>>>  Honestly, if we need to use Google WebRTC code for every WebRTC
>>>>> project then that means that the specifications are BAD (how can it be
>>>>> different after mandating the usage of the painful SDP O/A?).
>>>>>
>>>>
>>>> Again, you don't *need* it, but it's there for you if you want to reuse
>>>> some
>>>> of the code. For example, the existence of an open-source database (e.g.
>>>> PostgreSQL) does not preclude the existence of commercial
>>>> implementations
>>>> such as SQL Server.
>>>>
>>>> Gili
>>>>
>>>
>>>
>>>
>>
>>
>