We would like to announce that a new open source project is about to land in src/third_party/webrtc.
All details about WebRTC in general can be found at http://www.webrtc.org/. Our goal is to enable Chrome with Real-Time Communications (RTC) capabilities via simple Javascript APIs. We are working hard to provide full RTC support in Chrome all the way from WebKit down to the native audio and video parts. When we are done, any web developer shall be able to create RTC applications, like the Google Talk client in Gmail, without using any plugins but only WebRTC components that runs in the sandbox.
> We would like to announce that a new open source project is about to land > in src/third_party/webrtc.
> All details about WebRTC in general can be found at http://www.webrtc.org/. > Our goal is to enable Chrome with Real-Time Communications (RTC) > capabilities via simple Javascript APIs. We are working hard to provide full > RTC support in Chrome all the way from WebKit down to the native audio and > video parts. When we are done, any web developer shall be able to create RTC > applications, like the Google Talk client in Gmail, without using any > plugins but only WebRTC components that runs in the sandbox.
When adding a third party as a line in DEPS, is it possible to overlap the README.chromium and LICENSES (by committing to chromium's tree), or do you need to check those in upstream? It'd be great if that info (add third_party DEPS) were added to the adding third party libraries<http://www.chromium.org/developers/adding-3rd-party-libraries>page, as I would guess/hope that's the more common/preferred than committing third party source directly into chromium's tree.
-SCR
On Mon, Jun 20, 2011 at 7:07 AM, Paweł Hajdan, Jr. <phajdan...@chromium.org>wrote:
> On Fri, Jun 17, 2011 at 22:00, Henrik Andreasson <henr...@chromium.org>wrote:
>> We would like to announce that a new open source project is about to land >> in src/third_party/webrtc.
>> All details about WebRTC in general can be found at >> http://www.webrtc.org/. Our goal is to enable Chrome with Real-Time >> Communications (RTC) capabilities via simple Javascript APIs. We are working >> hard to provide full RTC support in Chrome all the way from WebKit down to >> the native audio and video parts. When we are done, any web developer shall >> be able to create RTC applications, like the Google Talk client in Gmail, >> without using any plugins but only WebRTC components that runs in the >> sandbox.
On Mon, Jun 20, 2011 at 19:20, Sheridan Rawlins <s...@chromium.org> wrote: > When adding a third party as a line in DEPS, is it possible to overlap the > README.chromium and LICENSES (by committing to chromium's tree), or do you > need to check those in upstream?
You can have a third_party/webrtc directory with README.chromium file in the main svn repo, and fetch the upstream repo via DEPS to third_party/webrtc/src. Then in README.chromium you can set the path to the license file to say src/LICENSE and it should work.
> It'd be great if that info (add third_party DEPS) were added to the adding > third party libraries<http://www.chromium.org/developers/adding-3rd-party-libraries>page, as I would guess/hope that's the more common/preferred than committing > third party source directly into chromium's tree.
> -SCR
> On Mon, Jun 20, 2011 at 7:07 AM, Paweł Hajdan, Jr. < > phajdan...@chromium.org> wrote:
>> Just checking: is there a README.chromium file for it, and have you run >> "src/tools/licenses.py scan"?
>> On Fri, Jun 17, 2011 at 22:00, Henrik Andreasson <henr...@chromium.org>wrote:
>>> We would like to announce that a new open source project is about to land >>> in src/third_party/webrtc.
>>> All details about WebRTC in general can be found at >>> http://www.webrtc.org/. Our goal is to enable Chrome with Real-Time >>> Communications (RTC) capabilities via simple Javascript APIs. We are working >>> hard to provide full RTC support in Chrome all the way from WebKit down to >>> the native audio and video parts. When we are done, any web developer shall >>> be able to create RTC applications, like the Google Talk client in Gmail, >>> without using any plugins but only WebRTC components that runs in the >>> sandbox.
Actually, we don't need to check a README into another directory. We just need to update /trunk/src/tools/licenses.py with logic to find the LICENSE/COPYING files for webrtc.
> On Mon, Jun 20, 2011 at 19:20, Sheridan Rawlins <s...@chromium.org> wrote:
>> When adding a third party as a line in DEPS, is it possible to overlap the >> README.chromium and LICENSES (by committing to chromium's tree), or do you >> need to check those in upstream?
> You can have a third_party/webrtc directory with README.chromium file in > the main svn repo, and fetch the upstream repo via DEPS to > third_party/webrtc/src. Then in README.chromium you can set the path to the > license file to say src/LICENSE and it should work.
>> It'd be great if that info (add third_party DEPS) were added to the adding >> third party libraries<http://www.chromium.org/developers/adding-3rd-party-libraries>page, as I would guess/hope that's the more common/preferred than committing >> third party source directly into chromium's tree.
>> -SCR
>> On Mon, Jun 20, 2011 at 7:07 AM, Paweł Hajdan, Jr. < >> phajdan...@chromium.org> wrote:
>>> Just checking: is there a README.chromium file for it, and have you run >>> "src/tools/licenses.py scan"?
>>> On Fri, Jun 17, 2011 at 22:00, Henrik Andreasson <henr...@chromium.org>wrote:
>>>> We would like to announce that a new open source project is about to >>>> land in src/third_party/webrtc.
>>>> All details about WebRTC in general can be found at >>>> http://www.webrtc.org/. Our goal is to enable Chrome with Real-Time >>>> Communications (RTC) capabilities via simple Javascript APIs. We are working >>>> hard to provide full RTC support in Chrome all the way from WebKit down to >>>> the native audio and video parts. When we are done, any web developer shall >>>> be able to create RTC applications, like the Google Talk client in Gmail, >>>> without using any plugins but only WebRTC components that runs in the >>>> sandbox.
This is a layering violation since chrome consumes webrtc and modules lower down in the chain can't include code from their consumers. The good news is that this is pretty easy to fix. The usual pattern is to have an embedder API that chrome implements. Before using the third_party code, it's given a pointer to the embedder's implementation of the API.
On Fri, Jun 17, 2011 at 1:00 PM, Henrik Andreasson <henr...@chromium.org>wrote:
> We would like to announce that a new open source project is about to land > in src/third_party/webrtc.
> All details about WebRTC in general can be found at http://www.webrtc.org/. > Our goal is to enable Chrome with Real-Time Communications (RTC) > capabilities via simple Javascript APIs. We are working hard to provide full > RTC support in Chrome all the way from WebKit down to the native audio and > video parts. When we are done, any web developer shall be able to create RTC > applications, like the Google Talk client in Gmail, without using any > plugins but only WebRTC components that runs in the sandbox.
On Wed, Jun 22, 2011 at 9:35 AM, John Abd-El-Malek <j...@chromium.org> wrote: > Congrats on the launch! > I just noticed that the code in third_party/webrtc directly includes code > from chrome (I mean all of the chrome code, not just src/chrome, i.e. also > src/base, src/content) > http://codesearch.google.com/codesearch#search/&exact_package=chromiu... > This is a layering violation since chrome consumes webrtc and modules lower > down in the chain can't include code from their consumers. The good news is > that this is pretty easy to fix. The usual pattern is to have an embedder > API that chrome implements. Before using the third_party code, it's given a > pointer to the embedder's implementation of the API.
This also makes making certain changes to base exceedingly difficult because of the circular dependency. For example, you include base/values. This means that nobody can now change any part of base/values since webrtc is pulled at a specific revision from a different repository. In the past this has had a significant impact on our ability to make improvements, and we've worked hard to reduce the instances of these dependencies.
On Wed, Jun 22, 2011 at 9:35 AM, John Abd-El-Malek <j...@chromium.org> wrote: > Congrats on the launch!
> I just noticed that the code in third_party/webrtc directly includes code > from chrome (I mean all of the chrome code, not just src/chrome, i.e. also > src/base, src/content)
Hmm, this also looks like another copy of libjingle. Don't we already have a copy of libjingle at src/third_party/libjingle/. Is it a temporary state that we have a second copy of that library (w/ mods)? I'm sure this has something to do with how development had to exist on a branch up until now.
> This is a layering violation since chrome consumes webrtc and modules lower > down in the chain can't include code from their consumers. The good news is > that this is pretty easy to fix. The usual pattern is to have an embedder > API that chrome implements. Before using the third_party code, it's given a > pointer to the embedder's implementation of the API.
> On Fri, Jun 17, 2011 at 1:00 PM, Henrik Andreasson <henr...@chromium.org>wrote:
>> We would like to announce that a new open source project is about to land >> in src/third_party/webrtc.
>> All details about WebRTC in general can be found at >> http://www.webrtc.org/. Our goal is to enable Chrome with Real-Time >> Communications (RTC) capabilities via simple Javascript APIs. We are working >> hard to provide full RTC support in Chrome all the way from WebKit down to >> the native audio and video parts. When we are done, any web developer shall >> be able to create RTC applications, like the Google Talk client in Gmail, >> without using any plugins but only WebRTC components that runs in the >> sandbox.
On Wed, Jun 22, 2011 at 9:40 AM, Brett Wilson <bre...@chromium.org> wrote: > On Wed, Jun 22, 2011 at 9:35 AM, John Abd-El-Malek <j...@chromium.org> > wrote: > > Congrats on the launch! > > I just noticed that the code in third_party/webrtc directly includes code > > from chrome (I mean all of the chrome code, not just src/chrome, i.e. > also > > src/base, src/content)
> http://codesearch.google.com/codesearch#search/&exact_package=chromiu... > > This is a layering violation since chrome consumes webrtc and modules > lower > > down in the chain can't include code from their consumers. The good news > is > > that this is pretty easy to fix. The usual pattern is to have an embedder > > API that chrome implements. Before using the third_party code, it's given > a > > pointer to the embedder's implementation of the API.
> This also makes making certain changes to base exceedingly difficult > because of the circular dependency. For example, you include > base/values. This means that nobody can now change any part of > base/values since webrtc is pulled at a specific revision from a > different repository. In the past this has had a significant impact on > our ability to make improvements, and we've worked hard to reduce the > instances of these dependencies.
On Wed, Jun 22, 2011 at 9:40 AM, Brett Wilson <bre...@chromium.org> wrote: > On Wed, Jun 22, 2011 at 9:35 AM, John Abd-El-Malek <j...@chromium.org> wrote: >> Congrats on the launch! >> I just noticed that the code in third_party/webrtc directly includes code >> from chrome (I mean all of the chrome code, not just src/chrome, i.e. also >> src/base, src/content) >> http://codesearch.google.com/codesearch#search/&exact_package=chromiu... >> This is a layering violation since chrome consumes webrtc and modules lower >> down in the chain can't include code from their consumers. The good news is >> that this is pretty easy to fix. The usual pattern is to have an embedder >> API that chrome implements. Before using the third_party code, it's given a >> pointer to the embedder's implementation of the API.
> This also makes making certain changes to base exceedingly difficult > because of the circular dependency. For example, you include > base/values. This means that nobody can now change any part of > base/values since webrtc is pulled at a specific revision from a > different repository. In the past this has had a significant impact on > our ability to make improvements, and we've worked hard to reduce the > instances of these dependencies.
I see the base/values usage is from libjingle which you didn't write. But the same problem applies to your content includes. Actually, it's worse since content changes much faster than base.
On Wed, Jun 22, 2011 at 9:41 AM, Darin Fisher <da...@chromium.org> wrote: > On Wed, Jun 22, 2011 at 9:35 AM, John Abd-El-Malek <j...@chromium.org> wrote:
>> Congrats on the launch! >> I just noticed that the code in third_party/webrtc directly includes code >> from chrome (I mean all of the chrome code, not just src/chrome, i.e. also >> src/base, src/content)
> Hmm, this also looks like another copy of libjingle. Don't we already have > a copy of libjingle at src/third_party/libjingle/. Is it a temporary state > that we have a second copy of that library (w/ mods)? I'm sure this has > something to do with how development had to exist on a branch up until now.
There also appears to be another copy of libvpx inside webrtc.
>> This is a layering violation since chrome consumes webrtc and modules >> lower down in the chain can't include code from their consumers. The good >> news is that this is pretty easy to fix. The usual pattern is to have an >> embedder API that chrome implements. Before using the third_party code, it's >> given a pointer to the embedder's implementation of the API.
>> On Fri, Jun 17, 2011 at 1:00 PM, Henrik Andreasson <henr...@chromium.org> >> wrote:
>>> We would like to announce that a new open source project is about to land >>> in src/third_party/webrtc. >>> All details about WebRTC in general can be found >>> at http://www.webrtc.org/. Our goal is to enable Chrome with Real-Time >>> Communications (RTC) capabilities via simple Javascript APIs. We are working >>> hard to provide full RTC support in Chrome all the way from WebKit down to >>> the native audio and video parts. When we are done, any web developer shall >>> be able to create RTC applications, like the Google Talk client in Gmail, >>> without using any plugins but only WebRTC components that runs in the >>> sandbox.
On Wed, Jun 22, 2011 at 9:42 AM, Brett Wilson <bre...@chromium.org> wrote: > On Wed, Jun 22, 2011 at 9:40 AM, Brett Wilson <bre...@chromium.org> wrote: > > On Wed, Jun 22, 2011 at 9:35 AM, John Abd-El-Malek <j...@chromium.org> > wrote: > >> Congrats on the launch! > >> I just noticed that the code in third_party/webrtc directly includes > code > >> from chrome (I mean all of the chrome code, not just src/chrome, i.e. > also > >> src/base, src/content)
> http://codesearch.google.com/codesearch#search/&exact_package=chromiu... > >> This is a layering violation since chrome consumes webrtc and modules > lower > >> down in the chain can't include code from their consumers. The good news > is > >> that this is pretty easy to fix. The usual pattern is to have an > embedder > >> API that chrome implements. Before using the third_party code, it's > given a > >> pointer to the embedder's implementation of the API.
> > This also makes making certain changes to base exceedingly difficult > > because of the circular dependency. For example, you include > > base/values. This means that nobody can now change any part of > > base/values since webrtc is pulled at a specific revision from a > > different repository. In the past this has had a significant impact on > > our ability to make improvements, and we've worked hard to reduce the > > instances of these dependencies.
> I see the base/values usage is from libjingle which you didn't write. > But the same problem applies to your content includes. Actually, it's > worse since content changes much faster than base.
(just to clarify, it looks like libjingle was modified to depend on base (and net) when it depended on content)
My idea is to have an Flash or HTML5 app integrated on Chrome to have
it used on video chat using Gmail or Gtalk but also add an API to
allow developers to integrate it in their applications and an option
to deactivate it on the browser options if it makes it slow on old
computers .
At first I would like to thank you all for such an awesome browser!
I am new to this project, but WebRTC is extremely interesting subject
for me.
Unfortunately I could not find /src/third_party/webrtc directory in my
today's git clone. Is there probably another repo with WebRTC
integrated?
I would like to see the changes in WebKit and in the browser as well..
Is it planned to integrate WebRTC into original WebKit our Chromium
will use its own WebKit tree?
Best regards,
Dmitry
On 18 июн, 00:00, Henrik Andreasson <henr...@chromium.org> wrote:
> We would like to announce that a new open source project is about to land in
> src/third_party/webrtc.
> All details about WebRTC in general can be found athttp://www.webrtc.org/.
> Our goal is to enable Chrome with Real-Time Communications (RTC)
> capabilities via simple Javascript APIs. We are working hard to provide full
> RTC support in Chrome all the way from WebKit down to the native audio and
> video parts. When we are done, any web developer shall be able to create RTC
> applications, like the Google Talk client in Gmail, without using any
> plugins but only WebRTC components that runs in the sandbox.
On 5 July 2011 15:17, Dmitry Matveev <dmm1...@gmail.com> wrote:
> Hello Chromium developers,
> At first I would like to thank you all for such an awesome browser!
> I am new to this project, but WebRTC is extremely interesting subject > for me. > Unfortunately I could not find /src/third_party/webrtc directory in my > today's git clone. Is there probably another repo with WebRTC > integrated?
> webrtc would not normally arrive via git. Have you run gclient config /
> I would like to see the changes in WebKit and in the browser as well.. > Is it planned to integrate WebRTC into original WebKit our Chromium > will use its own WebKit tree?
> Best regards, > Dmitry
> On 18 июн, 00:00, Henrik Andreasson <henr...@chromium.org> wrote: > > We would like to announce that a new open source project is about to land > in > > src/third_party/webrtc.
> > All details about WebRTC in general can be found athttp:// > www.webrtc.org/. > > Our goal is to enable Chrome with Real-Time Communications (RTC) > > capabilities via simple Javascript APIs. We are working hard to provide > full > > RTC support in Chrome all the way from WebKit down to the native audio > and > > video parts. When we are done, any web developer shall be able to create > RTC > > applications, like the Google Talk client in Gmail, without using any > > plugins but only WebRTC components that runs in the sandbox.
