Each is entitled his own opinion. My worry isn’t with you running off and building WebRTC into WebKit instead of letting Apple do the work. My worry is that you are defocusing yourselves from what can bring value (and revenue) to your companies.
For Ericsson that might not be an issue, but for Temasys…

I fail to understand the business case behind this, and you haven’t been able to explain it clear enough for me to understand. Feel free to see it as my own failing for being stupid.

You are almost making my point here 🙂 What you are potentially missing is that when/if Apple decides to add WebRTC to their port of WebKit, it will be largely based on the code that we are landing right now as it is generic for all ports of WebKit (WebCore).

I realized I hadn’t answered your speculation, sorry about that.
Yes, webrtc.org code is … problematic to manage. Yes, when we first came out with the free plugin, we realized we were spending 80% of our time handling changes in libwebrtc against 20% in the plugin code. No, we did not get burnt, we automated everything nicely, as we are using the stack in several products, it was making a lot of sense. We are about to provide, likely for free, precompiled and pre tested webrtc libraries. You can see the public automatic builds there already:
http://my.cdash.org/index.php?project=libwebRTC&date=
You can see builds result for linux, mac, windows, 32b/64b, debug, release.
Far from burnt.

The homework comment was related to the post itself.

As for web view, the one on android is indeed pretty recent (4.3 if i recall correctly) and still need love. The one in safari is … older. We both agree that it is still too hard, and we plan to make it easier for developer to just use webview instead of having to maintain a full webrtc stack. Note that on android, however difficult it may be to use web view with webrtc support, it’s still easier than repurposing an existing webrtc stack. (kudos for the parrot demo, leveraging janus was a nice hack).

@tsahi,

In the meantime, less than one hour and a half ago, apple accepted yet another patch bringing webrtc to webkit 😉 Actions speaks more than words.
http://trac.webkit.org/changeset/182275

“Talk is cheap, show me the code”, Torvalds, Linus (2000-08-25).

I mostly don’t know how to react to that 😉

Stefan,

Let’s face the truth. We live in a mobile duopoly. The only 2 players in mobile operating systems these days are Apple and Google. No one else comes close to being relevant. Not Firefox OS. Not Blackberry. Not Microsoft Windows Phone. Not Samsung Bada. Not Jolla. Only Apple and Google.

This translates to iOS and Android which translates to Safari and Chrome which then translates to WebKit and Blink.

Blink is relevant in the context of Android and Chrome. WebKit is relevant in the context of iOS, Safari, the iPhone and the iPad. As stated earlier, WebKit in the scope of Safari is controlled by Apple, which will do as it pleases with whatever goes in its devices.

How is WebKit important out of the scope of iOS in an extent that isn’t overshadowed by Apple’s WebKit and Google’s Blink? By saying that Nokia uses it?

Sure, Mozilla has a different API implementation than Google Chrome, but Mozilla does not yet have a large enough footprint on the ever more important mobile platforms.

Also, I do not share Tsahi’s (arguably Google-centric view) that WebKit is no longer relevant after being forked in to Blink. Google leaving was to some extent negative for WebKit, but saying it is irrelevant is at least a few steps too far.

Stefan

As someone who has tried to use an embedded webview to support a webRTC call
I can tell you that it is not easy. The only webview that supports webRTC at the moment is the one in android 5 (which is a rare beast still) – and it is 10 versions behind the public chrome release – which means it barely interops with the chrome browser on the same device, let alone anything else. (Enough homework?)

Alex, somehow, I expected this 🙂

Using webview inside an app is nice, but it ends up using the browser renderer that the mobile OS vendor decided to place in his smartphone, which brings us back to… Apple.
I’d also suggest reading some other views re:mobile such as this one: http://www.mobilephonedevelopment.com/archives/2200
The jury is still out there for best way to implement apps. I haven’t made up my mind which way is better.

As for the list of “users”:
– Samsung phones. That would be their Bada ones, which are nowhere
– Nokia. Sure
– Blackberry. Yap
– Nintendo. Seriously?
– PlayStation. Got me there, but Sony has its hands full with XBox and Android competition anyway
– Amazon Kindle. That’s Android. When they decide to upgrade, it will be Blink and not WebKit
– Set top boxes. I understand I need to defuse this bomb, but would require a whole post. Expect this later this month
– Embedded displays. A lot of them are switching to Android anyway

And yes, while Blink is a fork of WebKit, do they share such resemblance after two years? If they had, then there would be no need for the WebRTC in WebKit initiative – you’d just need to merge the files and be done with it 🙂

Never did do my homework anyway.

native apps vs web app – wait … wrong debate. Most native apps use web view anyway
– http://developer.telerik.com/featured/what-is-a-hybrid-mobile-app/
– http://www.stevesouders.com/blog/2014/10/09/do-u-webview/

nobody uses webkit/webview – right…
– http://en.wikipedia.org/wiki/WebKit
— samsung phones
— nokia phones
— BB phones
— nintendo, playstation, …
— amazon kindle,
— most of the set up boxes (http://en.wikipedia.org/wiki/OpenTV)
— the majority of device with embedded display

chrome forked webkit into blink – or not (webcore is a subpart of webkit)
– http://en.wikipedia.org/wiki/Blink_(layout_engine)
– https://chromium.googlesource.com/external/Webkit/