Still only supports proprietary codecs from what I understand. So not "full".
Apple Announces Full WebRTC Support in Safari 11
71–80 of 167 posts
Re: Apple Announces Full WebRTC Support in Safari 11
#72Does this mean Apple may actually implement Service Workers and Web Push in the next Safari?? :)
It is completely hostile to users. If I close a web page I expect everything related to that web page to stop. Immediately. I don't expect there to be lingering background threads consuming battery life, network data and disk storage. And in Chrome you can only discover service workers by enabling a Debug mode and memorising a specific URL. Exactly how does a non-developer figure out what is going on ?
If Apple had any sense they would ban service workers and instead propose use case specific, tightly focused and managed APIs that focus on security and battery life first.
Also just a hint at a future where Botnets are running in your browser:
https://sakurity.com/blog/2016/12/10/serviceworker_botnet.ht...
Re: Apple Announces Full WebRTC Support in Safari 11
#73Earlier quoted context omitted.
I doubt you'll see gaming pick up WebRTC for many of the reasons that Glenn build netcode.io[1]. It's overly complex and doesn't guarantee UDP which is a non-starter for most games. [1] http://new.gafferongames.com/post/why_cant_i_send_udp_packet... / https://github.com/networkprotocol/netcode.io
It guarantees UDP for all of the cases when UDP would work. You can choose to not use TCP if you like, though I think most games would actually desire a TCP fallback.
http://www.gamasutra.com/view/feature/131781/the_internet_su...
Re: Apple Announces Full WebRTC Support in Safari 11
#74Earlier quoted context omitted.
Apple has absolutely kneecapped web technologies. Mobile Safari has simple, egregious bugs that have been open for years. We're talking about things like being able to crash the browser with CSS or file selection, etc. It's impossible to make the case that Apple is just rejecting features for the sake of the user. The next question is why, and you'll need some creativity to come up with any other answer than pointing…
Posts like this genuinely confuse me. If all Apple cared about was the App Store then why do they continue to hire WebKit engineers and build new features ? It would be easier just to fork WebKit, never add anything new and deliberately make it so unusable that everyone rushes to apps.
I worked with a group of engineers full time for years around mobile/iOS, and we were pretty amazed at how severe but unaddressed these bugs were. The move to WKWebView was helpful, but still lacking. The app store parallel that you take issue with is an easy one to make when you contrast those failings against the talent and financial bandwidth of a company that size.
Re: Apple Announces Full WebRTC Support in Safari 11
#75Apple and Microsoft waited five years to deploy this thing. Given how quickly it was implemented and adopted by other browsers, I have to wonder what their motives were for deliberately not integrating it; because frankly they could've done it pretty quickly at any point in the last five years. I remember having to integrate WebRTC through cordova (thank goodness somebody did it first) a couple years ago, and wonderi…
WebRTC is actually quite complicated to implement and it took a large effort by a big chunk of the WebKit team, even though we had a lot of code that we could reuse. People have a lot of theories about Safari deliberately omitting one feature or another, but the truth is there's only so much we can do at once. ETA: If you look at the page counts of all the required specs (ECMAScript APIs, WebRTC protocol specs, under…
I would think the greatest barrier to integrating Opus would be getting Apple legal to agree not to sue other Opus adopters . Fair enough, but that's not five years worth of legal research. I would be gobsmacked if Apple bothered to write their own encoder or decoder just for WebKit, you don't need to read the bitstream format documentation.
And again, Apple has so much cash on hand that it takes the accountants five minutes to walk across a line on their balance sheets. Maybe the rest of you are busy, fine, but there are people who are qualified to put WebRTC in WebKit in the general public. Apple could send some money to the qualified people at Collabora, Igalia, or Ericsson Research (who I think have had WebRTC in Webkit since 2015).
All in all, it's absolutely bogus that Safari hasn't had WebRTC for at least two years already. You can make all the excuses you want, but this API drives more customer value than any ES6 feature. Nobody actually deploys ES6 on the web today, because it has forced browser vendors to completely reengineer their compilers, taking half a decade each, and as a result it has not been deployed long enough with decent performance to offer any value. WebRTC has been deployed for going on five years in valuable applications which are otherwise completely impossible on the web, half the other crap has no userbase, and offers questionable tangible value.
Re: Apple Announces Full WebRTC Support in Safari 11
#76Re: Apple Announces Full WebRTC Support in Safari 11
#77Does this mean Apple may actually implement Service Workers and Web Push in the next Safari?? :)
Re: Apple Announces Full WebRTC Support in Safari 11
#78I saw this yesterday on twitter and my thought was "they don't support webrtc yet?!? seriously?" It sometimes baffles me how apple is holding up progress on the web - and that they aren't criticized more for it.
They're not holding up progress. They have different objectives, and chief among them is power efficiency. Chrome eats up a lot more battery life than Safari.[1] So did Flash (among other conflicts), and I think we all accept now that "holding that up" was good for the web in the long run. Apple tends to take a little longer and suffer a little short-term pain to get it right in the long run. [1] https://daringfireba…
Re: Apple Announces Full WebRTC Support in Safari 11
#79Earlier quoted context omitted.
In a sense you're right. But we also want to make sure WebRTC websites don't blow out your battery, and we went to some effort to make sure it uses efficient video encoding/decoding paths. That said, this was not a majority of the effort.
Besides battery life, Chrome on the Mac prevents sleep indefinitely sometimes. If you check with pmset -g assertions, you'll see Chrome saying "WebRTC has active PeerConnections". No thanks Google, you shouldn't get to decide when my PC goes into sleep mode. I really hope Safari is better than that... Edit: just as i'm typing this, Chrome has: pid 19325(Google Chrome): [0x001ccbbb00018b19] 01:55:40 NoIdleSleepAsserti…
If you go to Window > Task Manager it'll tell you which PID corresponds to which tab.
Re: Apple Announces Full WebRTC Support in Safari 11
#80Earlier quoted context omitted.
What about a WebRTC version of Twitch.tv? Is that feasible in 5 or 10 years? Twitch does transcoding and I'm not sure how transcoding would work with WebRTC.
It would probably be possible for smaller communities today, given how cheap bandwidth already is. For comparison, I'm currently paying ~$13/mo for a (symmetric) gigabit connection. The main reasons for transcoding are downstream bandwidth usage and codec support. WebRTC mandates VP8, so codecs shouldn't be an issue. Downstream bandwidth usage probably wouldn't be a major concern when it's viable to stream at 1080p t…