-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spec-compliant webrtc promised in README #11
Comments
Personally, I agree with the comments on |
@fippo It's the goal, it's certainly not the current state across the board right now. I'm working on getting this to where it needs to be still. There are tickets open to replace getUserMedia with the mediaDevices API, the end goal is to not deviate from the spec at all. Still not sure why you think a minor API deviation is enough to justify your unprofessional behavior calling this a ripoff and a "lame copy" in the other github issue. Grow up. |
@RangerMauve Currently experimenting with using mutation observer + some monkey patching to make srcObject work. If we can get rid of attachStream I'd be a happy camper. Relevant tickets: |
@contra i don't think I used 'ripoff', I only use that for license violations. |
@fippo Making WebRTC work across browsers is an idea that can be stolen? If you're going to accuse somebody of being a thief don't be a fucking coward about it, just come out and say it. Be specific. What ideas were stolen? Who deserves credit? In all the years I've been working in open source I've never encountered somebody so petulant and hostile. Is this how &yet/tokbox/wherever-the-fuck-you-work participates in the community? Seriously, get a fucking grip on yourself. |
@contra: attachStream is the idea you're borrowing. No licensing issues here even though I don't see why you had to change the name (bikeshed argument). The problem I have with that is that you are promoting the idea of yet another abstraction ontop of the W3C API. Which is somewhat counterproductive given that it is already hard to get developers to write code that works not only in Chrome. p.s.: my opinions are my own, as are the fights I am picking. |
@fippo You were the first person to come up with the concept of attaching video to a DOM element? Congratulations on such an original idea! I'm sure it was very difficult to think of and your peers must be very proud of you. For the record: I'm not promoting any abstraction on top of the W3C API - this project is a work in progress, which is a fancy term for "it's not finished yet" (hint: I just linked you to the roadmap). I've tried to be civil and listen to your arguments but I'm not going to waste anymore time listening to you spout bullshit and attack me. I get it, you're trying to look tough - I opened an issue on your repo a year ago asking you to add a piece of documentation. You just saw it today (nice response time), got really defensive, and now you feel like you have to come after me for that. I'm honestly embarrassed for you - seriously. And yes, this definitely reflects on you and your employer considering how your job is open source webrtc at tokbox and you're attacking open source webrtc projects. |
the README promises this:
rtc-everywhere gives you spec-compliant WebRTC
This is misleading at best.
The specification defines a set of APIs for the browser. It does not define 'rtc.RTCPeerConnection' nor anything else rtc. I don't see support for e.g. the mandatory promise-based APIs on platforms where it is perfectly possible to implement with little effort.
If you promise spec-compliance, you don't extend or change the API.
No matter how much you prefer node-style API.
this is a step backward from setting srcObject on the media element.
Just saying. We can agree to disagree.
The text was updated successfully, but these errors were encountered: