WebRTC PeerConnection part

[Iskren Chernev]

I was reading mozilla's code related to WebRTC and I have some questions about using WebRTC in a different project:
* media/webrtc/signaling includes the "missing" PeerConnection implementation from webrtc/trunk. It seems like you (mozilla) implemented it -- the files have a MPL licence at the top, but the gyp file is from chromium? Do you intend to merge this upstream to WebRTC, because the current peerconnection webrtc includes libjingle and talk libraries from google as deps? Same question applies for media/mtransport, which (according to the comments inside) is intended for use only in webrtc context.
* media/webrtc/webrtc_update.sh fetches WebRTC repo, but the code that ends up in webrtc_update folder (the code that you're supposed to use as the new version?) has much more third_party code than the existing webrtc code in mozilla's repo (like libjingle for example).

Regards,
Iskren

[Ethan Hugg]

Hi Iskren,

The gyp file in not from Chromium. We built it for
media/webrtc/signaling and as far as I know do not intend to merge
upstream to the webrtc.org code which is in media/webrtc/trunk. We
are using gyp files now in places other than code shared with
Chromium.

Cheers,

-EH

> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media

[Iskren Chernev]

> The gyp file in not from Chromium.

Ah ok, I was confused by "chromium_code": 1 in the beginning :)

> We built it for
> media/webrtc/signaling and as far as I know do not intend to merge
> upstream to the webrtc.org code which is in media/webrtc/trunk.

OK. I hope that all implementations of the PeerConnection part will be compatible with each other, or an implementation will establish itself as "the right one" soon :) It won't be an easy task tough -- sockets, threads, signals/slots, timers have to be implemented in a cross-platform fashion (boost maybe?).

> Cheers,
> -EH

Thank you for the info!
Regards,
Iskren

[Randell Jesup]

On 11/1/2012 7:09 PM, Iskren Chernev wrote:
> I was reading mozilla's code related to WebRTC and I have some questions about using WebRTC in a different project:
> * media/webrtc/signaling includes the "missing" PeerConnection implementation from webrtc/trunk. It seems like you (mozilla) implemented it -- the files have a MPL licence at the top, but the gyp file is from chromium? Do you intend to merge this upstream to WebRTC, because the current peerconnection webrtc includes libjingle and talk libraries from google as deps? Same question applies for media/mtransport, which (according to the comments inside) is intended for use only in webrtc context.

There's a benefit seen to have at least two separate implementations of
a feature. We are relying on the core non-third-party code from
webrtc.org (it would take too much time to reimplement all that.
Signaling and transport in particular seemed ideal cases where
alternative implementations would help avoid bugs getting baked in
(often if everyone uses the same code, no one notices a bug because they
all have it).

> * media/webrtc/webrtc_update.sh fetches WebRTC repo, but the code that ends up in webrtc_update folder (the code that you're supposed to use as the new version?) has much more third_party code than the existing webrtc code in mozilla's repo (like libjingle for example).

There are more manual steps after this, because we found the automated
script merged too much version-control history into the main repository,
causing hg to be slow and large(r). We've been hand-merging to
mozilla-central after the script runs, but will be revising the update
procedure to try to re-automate it as much as possible.

--
Randell Jesup
Mozilla Corp; WebRTC module owner

[Iskren Chernev]

On Friday, November 2, 2012 6:39:07 AM UTC-7, Randell Jesup wrote:
> There are more manual steps after this, because we found the automated
> script merged too much version-control history into the main repository,
> causing hg to be slow and large(r). We've been hand-merging to
> mozilla-central after the script runs, but will be revising the update
> procedure to try to re-automate it as much as possible.

I see. I was trying to use it, because it seemed to me that webrtc's
PeerConnection had too much dependencies, and since you have support for it
I guessed I can use your fetch-only-what-is-needed script. Then I figured out
your implementation depends on some NS stuff... so I guess I'll stick with the
libjingle implementation for now.

Thank you for the explanations, and keep on with the good work!