WebRTC support

[coreyauger]

I noticed that you say IE-only, Chrome-only, FF-only, and in general browser-specific attributes will not be present. Does this mean you would prefer WebRTC to stay out of the scalajs dom for now?

What about things like getUserMedia. Perhaps that could be added in a similar fashion as Vibrate in experimental. While leaving things like IceCandidate, SessionDescription, ect .. to user code base for now.. thought ?

I am happy to take this on if you like. I will wait to hear what you think is the best approach for this.

Thanks.

[mseddon]

Aha. Since that was written, we have added the org.scalajs.dom.experimental package, as you have found- in which things like WebRTC are welcome. Personally, I would love to see WebRTC in this library, but I've not found the time to add it.

I think it seems sensible to implement IceCandidate and friends too- but they should probably sit in a org.scalajs.dom.experimental.webrtc package. getUserMedia can be pimped as in the Vibration API, as you mention. Perhaps simply through an implicit defined on the webrtc package object.

[lihaoyi]

yeah putting it in experimental would make sense. Someone should go
update the readme =D =D =D

On Fri, Nov 13, 2015 at 10:56 AM, mseddon notifications@github.com wrote:

Aha. Since that was written, we have added the
org.scalajs.dom.experimental package, as you have found- in which things
like WebRTC are welcome. Personally, I would love to see WebRTC in this
library, but I've not found the time to add it. I think it seems sensible
to implement IceCandidate and friends too- but they should probably sit
in a org.scalajs.dom.experimental.webrtc package.

—
Reply to this email directly or view it on GitHub
#171 (comment)
.

[mseddon]

@lihaoyi I just opened that file :D. Sadly it's Friday evening and I'm being dragged out as I type this. I'll PR that tomorrow unless someone else beats me to it. :)

[coreyauger]

Ok cool.. I will take this on :)

[coreyauger]

I think the first step will be to add the support described here
https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia

However.. there is a commonly used "support" file that the js community uses to establish support for webrtc... seen here.
https://github.com/HenrikJoreteg/webrtcsupport/blob/master/index-browser.js
and this
https://github.com/webrtc/adapter/blob/master/adapter.js

I am wondering if we want to include such a support file in our implementation as well ?

[coreyauger]

OK I have a good start to things here.
https://github.com/coreyauger/scala-js-dom/blob/webrtc-api/src/main/scala/org/scalajs/dom/experimental/WebRTC.scala

If you have a seconds.. take a glance and make sure I am not going off on a major tangent here :)

Thanks !

[mseddon]

LGTM so far! One thing I might suggest though is if it all sits in org.scalajs.dom.experimental.webrtc - there's quite a lot of classes in there that would otherwise clutter the experimental namespace. In my opinion it is probably nicer to just import experimental.webrtc._ than import experimental.{MediaStreamTrack, RTCIdentityAssertion ...}.

[mseddon]

In regards to the WebRTC js wrappers.. that one's a little trickier. Particularly at this point in time, afaik there are no un-prefixed webrtc implementations available. Maybe it would be good to have a method on a utility object that wires up the global namespace correctly here, since otherwise it definitely won't work for anyone :). Does anyone else has any thoughts on this?

[coreyauger]

Agreed on the namespace.. I will change that.

I think dom patching will be a good solution to start with. I noticed in scalajs 0.6.5 they added "Pseudo-union type". There is one place that this can be used in the WebRTC arguments... and this should help a lot in the conversion of typescript files to scalajs (as typescript supports these union types) ...Clearly something that is going to aid in the development and patching of JS .. while muddying the waters of the Scala world. My point here is that perhaps there is a way to add the kind of support we require at the @JSName level ...

Something like a list of fall-back names..
ex:

@JSName(["getUserMedia","webkitGetUserMedia"])

[mseddon]

Hmm, yes, since the addition of the experimental package, we are increasingly going to need a convenient way to manage these. We could add a helper method (untested code) like:

  def normalize(objIn: js.Any, name: String)(fallbacks: String*): Unit = {
    val obj = objIn.asInstanceOf[js.Dynamic]
    if(js.isUndefined(obj.selectDynamic(name)))
      for(fallback <- fallbacks if !js.isUndefined(obj.selectDynamic(fallback))) {
        obj.updateDynamic(name)(obj.selectDynamic(fallback))
        return
      }
  }

Which you might use like this:

      normalize(dom.navigator, "getUserMedia")("webkitGetUserMedia", "mozGetUserMedia")

You do, of course, need to call an initialize method to set up the shim (and the user must remember to do so :(), but perhaps a helper like this should be tucked away in ext or such to make this sort of thing less painful.

[mseddon]

@sjrd @lihaoyi any thoughts on how we should standardise the approach to this sort of problem?

[coreyauger]

Hi, I have a mostly working prototype here.
http://turn.conversant.im:8080

By mostly I mean the DOM is working as expected... My other project which will include some nice ways to setup and signal has a few bugs still. If interested those project exists here:
https://github.com/coreyauger/scala-js-webrtc
https://github.com/coreyauger/scala-webrtc-example

I would recommend that we suggest people use the webrtc supplied adapter.js file until the dust settles a bit more with the vendor boxing match. This will allow us to call the most up to date implementation.

Please take a look again at DOM integration.. and if it looks good I will submit the PR.
https://github.com/coreyauger/scala-js-dom/tree/webrtc-api

Also note that I have left datachannel as a TOOD which I should be able to work on some time in near future.

Thanks :)

[coreyauger]

Hi guys. I am going to go ahead and push this down the PR channel. Thanks.