4 ms·
None of the things listed as "not currently planned" are big surprises, though seeing WebRTC there is very disappointing. I've never seen "Object RTC" before,
by McGlockenshire 13y ago
None of the things listed as "not currently planned" are big surprises, though seeing WebRTC there is very disappointing. I've never seen "Object RTC" before, is it a competing effort, or a restandardization effort?
- dstorey 13y agoObject RTC is developed by a community group at the W3C. It includes people from Google, Microsoft and a number of telecom companies, amongst others http://www.w3.org/community/ortc/ http://www.w3.org/community/ortc/
- alfet 13y agoso whats the difference between the two? its the first time i hear about object RTC.
- elisee 13y agoMicrosoft had a competing proposal to WebRTC called CU-RTC-Web which, as far as I understand it, proposed to get rid of the Session Description Protocol (which is text-based and thus difficult to parse/edit) and provide lower-level APIs instead (details here: http://www.tokbox.com/blog/what-the-cu-rtc-web-vs-webrtc-debate-means-for-developers/ http://www.tokbox.com/blog/what-the-cu-rtc-web-vs-webrtc-deb...). I've just started reading up on ObjectRTC but I believe it plans to offer an API to replace SDP too and Microsoft has moved to it since it's similar to their CU-RTC-Web proposal. All in all, it looks like this will delay the adoption of WebRTC everywhere but will be for the best in terms of API and developer experience in the end.
- amaks 13y ago"Lowe level API instead" suspiciously sounds like a lock in tactic for a platform specific stuff (read Windows).
- orf 13y agoNo it doesnt
- fishy929 13y ago> which is text-based and thus difficult to parse/edit That's not what I normally conclude when I think "text-based."
- tkmcc 13y agoI think he means programmatically :).
- deleted 13y ago[deleted]
- nairteashop 13y agoIt's a nicer javascript object based API for interacting with WebRTC. WebRTC by default uses an SDP offer/answer based approach. Here is a more detailed rationale for this API: http://tools.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-01.txt http://tools.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-...
- BilalBudhani 13y ago"MathML" is listed as "not currently planned".
- SEMW 13y agoHonest question: now that mathjax has a high-quality pure-HTML/CSS output engine, does anyone still care about browser MathML support?
- cpncrunch 13y agoIMO getUserMedia is more useful than WebRTC.
- derefr 13y agoThose 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.
- cpncrunch 13y agoNot 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.
- derefr 13y agoI 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.
- cpncrunch 13y agoDid you actually get into the internals of WebRTC on your project? That is when you notice the overengineering. In our product, our customers generally want the session recorded, which doesn't seem possible with WebRTC. Also we need to provide group video, which peer-to-peer isn't very useful for (in terms of efficiency). That's not to say that WebRTC isn't useful in other use-cases (such as your product). However getUserMedia is more generic because it can be used in web conferencing products like ours. That is why I say that if browser developers don't want to implement the full WebRTC, they should at least implement getUserMedia.