<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 8/24/14, 8:37 AM, Alexandre GOUAILLARD wrote:<br>
<blockquote
cite="mid:CAHgZEq4CHL060Oru1yuckw056MH1CeL4HZTXOgcVUZNzvctXwA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>For clarification of the goals and the scope, we intend to
provide patches in webkit for webRTC. We would love to see
webRTC support in iOS and we understand that having it in
apple provided webkit (UIWebView) to comply to apple store
rule 2.17. We understand we do not have complete control over
the entire process, especially the eventual packaging and
deployment, and the timelines, and that apple does not comment
about this, but we thought implementing it in webkit was a
necessary prerequisite in any case. For the rest we will have
faith :-)</div>
<div><br>
</div>
<div>During a phone conversation with eric C, we've ben told
that we should start by making it happen in the macOS X port
as we would snot be able to build for iOS and because the
differences were not so big between the iOS and the macOS
ports.</div>
</div>
</blockquote>
Yep, that sounds like a good plan.<br>
<blockquote
cite="mid:CAHgZEq4CHL060Oru1yuckw056MH1CeL4HZTXOgcVUZNzvctXwA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>JO has been working on the Media Capture and Stream and
webRTC APIs for almost a year, and developed an IE and Safari
plugin that implements all of the APIs. He reads/speaks/write
web IDL fluently now, and now all the subtleties of the
constraints, streams, tracks, ect. I sit at the standard
committees and help with everything that is not clear from the
specs. Unfortunately, that does not help understand webkit
intricacies and that's where we are today.</div>
<div><br>
</div>
<div>We reached out to Eric C, Thiago from nokia (NIX port),
kirun from samsung, and started from there. I also speak
regularly with adam Be. from ericson at the w3c meetings. I
will jump in the project and add an additional senior staff,
so we should be 2~3 FTE starting tuesday. Looking at philippe
N works in WK2, it looks like you would be a reviewer of any
patch we would submit, correct? (<a moz-do-not-send="true"
href="https://bugs.webkit.org/show_bug.cgi?id=123158"
target="_blank">bug</a>)</div>
</div>
</blockquote>
I help from time to time but the right reviewers for work on
multimedia are Brent Fulgham, Eric Carlson, Jer Noble and Philippe
Normand.<br>
<blockquote
cite="mid:CAHgZEq4CHL060Oru1yuckw056MH1CeL4HZTXOgcVUZNzvctXwA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>With our target (iOS/MacOS X) should we target WK1 or WK2?
We plan to finalize the webcore part first, but we need to
target an app, and a port for testing. NIX does not seem to be
an option anymore.</div>
</div>
</blockquote>
Usually, what goes into the WebKit layer is small and WK1 and WK2
are done simultaneously. For the initial prototype, you can focus on
WebKit2 and port the code to WebKit1 once you have something stable.<br>
<br>
On OS X, WebKit2 is used by WKWebView and Safari, WebKit1 is used by
the WebView API. On iOS, WebKit2 is used by WKWebView and Safari,
WebKit1 is used by UIWebView.<br>
<br>
For initial prototyping, you can generally focus on WebKit2 first.<br>
<blockquote
cite="mid:CAHgZEq4CHL060Oru1yuckw056MH1CeL4HZTXOgcVUZNzvctXwA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>There also seem to have been a discussion about the design
(platform vs client) triggered by adam Be.. Anybody knows if
there was a conclusion? (<a moz-do-not-send="true"
href="https://bugs.webkit.org/show_bug.cgi?id=67946"
target="_blank">bug</a>) We would prefer putting a maximum
of common code in webcore, as proposed by adam.</div>
</div>
</blockquote>
The architecture depends on the backend but also security
considerations (especially with the access to hardware). You should
ask Eric Carlson for input.
<blockquote
cite="mid:CAHgZEq4CHL060Oru1yuckw056MH1CeL4HZTXOgcVUZNzvctXwA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>We are also contributing some tests to w3c (based on
testharness.js, testing the bindings and IDL only) that we
plan to use for testing. Dominique has recently committed the
tests for steams and tracks using the latest spec (<a
moz-do-not-send="true"
href="https://github.com/w3c/web-platform-tests/tree/master/mediacapture-streams"
target="_blank">here</a>). Is there anything we should
prepare in the layout tests for this as well? It looks like
the media stream tests have been excluded from the tests for
the time being.</div>
</div>
</blockquote>
That is a good start. You can import W3C tests into WebKit.<br>
<br>
To qualify for a release, you would need to have a lot more testing
than that. Given the scope of WebRTC, this will require improving
the testing infrastructure of WebKit.<br>
<blockquote
cite="mid:CAHgZEq4CHL060Oru1yuckw056MH1CeL4HZTXOgcVUZNzvctXwA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>We are trying to have a working implementation by oct 15th,
so we could send it for test around and get feedback in time
for discussion during the W3C technical plenary and advisory
committee meeting on oct. 27th, in San Jose, CA.</div>
</div>
</blockquote>
Honestly this seems a little short, WebRTC is big. Most non-trivial
features take several months to get in good shape with proper
testing and performance coverage.<br>
<br>
It is probably possible to get a working prototype in 2 months, but
this will require great review cycles.<br>
<br>
Benjamin<br>
</body>
</html>