Status IE – IE's feature status and plans • Hacker News Board

Re: Status IE – IE's feature status and plans

#31

Post by TheCoreh » Thu, Apr 03, 2014, 2:34 AM UTC

derefr wrote: post #29

JacobRossi wrote: post #14

Earlier quoted context omitted.

If feature status were a Facebook relationship status, many might say "it's complicated." ;-) Most of the time, it's not actually a question of engineering resources. Stay tuned as we update more and more stuff to "In Development". (I work for IE)

I'm curious--does this imply internal-politics problems (e.g. getting other departments to expose, and possibly backport, APIs that Chakra needs to consume to do the features), or just weird engineering challenges specific to the Chakra codebase?

I could see some conflicts of interest issues too. (e.g. implementing WebRTC could be against their interests - since Microsoft owns Skype, they might not want to lower the barrier of entry to a competitor.)

Re: Status IE – IE's feature status and plans

#32

Post by dstorey » Thu, Apr 03, 2014, 2:44 AM UTC

TheCoreh wrote: post #31

derefr wrote: post #29

Earlier quoted context omitted.

I'm curious--does this imply internal-politics problems (e.g. getting other departments to expose, and possibly backport, APIs that Chakra needs to consume to do the features), or just weird engineering challenges specific to the Chakra codebase?

I could see some conflicts of interest issues too. (e.g. implementing WebRTC could be against their interests - since Microsoft owns Skype, they might not want to lower the barrier of entry to a competitor.)

Microsoft are contributing to Object RTC, so I see this as unlikely.

Re: Status IE – IE's feature status and plans

#33

Post by wyuenho » Thu, Apr 03, 2014, 2:51 AM UTC

Does that mean we won't be able to see ES6 modules coming to IE anytime soon?

Re: Status IE – IE's feature status and plans

#34

Post by grumblestumble » Thu, Apr 03, 2014, 2:58 AM UTC

This is great. I realize that there are probably political hurdles to doing so, but it would be awesome if these linked to MDN in addition to MSDN / W3C / WebPlatform.

Re: Status IE – IE's feature status and plans

#35

Post by yeukhon » Thu, Apr 03, 2014, 3:03 AM UTC

I still don't understand why IE still mark Content Security Policy (CSP) under consideration given all other major browsers (Firefox, Chrome, Safari and Opera) have at least some version of CSP implemented.

I am actually very surprised they don't yet have HSTS implemented. IE is so much behind these security standard IMO. I don't know why they would push Web Crypto into 11+ when they don't even have CSP or HSTS implemented yet.

Given the standard, they should have HSTS, then CSP, then Web Crypto and then subresource integrity (which will probably take another year or two to stabilize a final draft for v1).

Is this list even up-to-date?

Re: Status IE – IE's feature status and plans

#36

Post by grumblestumble » Thu, Apr 03, 2014, 3:04 AM UTC

This is somewhat misleading WRT to Flexbox. IE10 "supports" the abandoned syntax, which is incompatible with the new proposal. It would be very useful if this was explicitly mentioned in cases where the API for these things is in flux.

Re: Status IE – IE's feature status and plans

#37

Post by cpncrunch » Thu, Apr 03, 2014, 3:17 AM UTC

derefr wrote: post #27

cpncrunch wrote: post #20

Earlier quoted context omitted.

IMO getUserMedia is more useful than WebRTC.

Those two things are... orthogonal? WebRTC is a transport for media and data streams, which looks somewhat like SCTP-over-DTLS-over-UDP. getUserMedia is a way to get a stream which can then be sent over a transport.

Not quite - getUserMedia is one part of WebRTC. If you use the 'full' WebRTC (i.e. RTCPeerConnection), you're tied into a certain architecture, which isn't generally useful if you already have a server architecture. getUserMedia is more useful in general for developing web conferencing solutions IMO.

I think a lot of browser developers (Safari/IE) are baulking at implementing google's WebRTC. I would hope they would at least offer getUserMedia even if they don't implement the full WebRTC.

If you've looked into WebRTC you'll see it is horrendously over-engineered. I was hoping to grab the AEC code, but gave up on that idea after looking into it in more detail.

Re: Status IE – IE's feature status and plans

#38

Post by dstorey » Thu, Apr 03, 2014, 4:13 AM UTC

paul7986 wrote: post #25

No web audio API? Are they building in an alternative? All other browsers support web audio. Why isn't MS following along?

It’s under consideration.

Re: Status IE – IE's feature status and plans

#39

Post by dstorey » Thu, Apr 03, 2014, 4:14 AM UTC

wyuenho wrote: post #33

Does that mean we won't be able to see ES6 modules coming to IE anytime soon?

I believe the data from the Chakra (IE’s JS engine) team hasn’t been updated yet.

Re: Status IE – IE's feature status and plans

#40

Post by derefr » Thu, Apr 03, 2014, 4:14 AM UTC

cpncrunch wrote: post #37

derefr wrote: post #27

Earlier quoted context omitted.

Those two things are... orthogonal? WebRTC is a transport for media and data streams, which looks somewhat like SCTP-over-DTLS-over-UDP. getUserMedia is a way to get a stream which can then be sent over a transport.

Not quite - getUserMedia is one part of WebRTC. If you use the 'full' WebRTC (i.e. RTCPeerConnection), you're tied into a certain architecture, which isn't generally useful if you already have a server architecture. getUserMedia is more useful in general for developing web conferencing solutions IMO. I think a lot of browser developers (Safari/IE) are baulking at implementing google's WebRTC. I would hope they would…

I don't see over-engineering in WebRTC; I see the same assisted-peer-to-peer routing required to support the major use-cases of traditional SIP:

1. When people are within the same firewall, they want to be able to communicate directly without routing anything but connection set-up through any servers; and

2. when people are members of the same corporation or mobile ISP, but are behind different firewalls, they want to be able to communicate by routing through the corporation/ISP's shared pool of TURN servers, instead of your service's hosted TURN servers.