From MozillaWiki
Jump to: navigation, search

« previous week | index | next week »

WebAPI Meeting Details

  • Tuesday 2014-03-11 - 8:00 am Pacific
  • Dial-in: Audio-only conference# 98413
    • People with Mozilla phones or softphones please dial x4000 Conf# 98413
    • US/Toll-free: +1 800 707 2533, (pin 4000) Conf# 98413
    • US/California/Mountain View: +1 650 903 0800, x4000 Conf# 98413
    • US/California/San Francisco: +1 415 762 5700, x4000 Conf# 98413
    • US/Oregon/Portland: +1 971 544 8000, x4000 Conf# 98413
    • CA/British Columbia/Vancouver: +1 778 785 1540, x4000 Conf# 98413
    • CA/Ontario/Toronto: +1 416 848 3114, x4000 Conf# 98413
    • UK/London: +44 (0)207 855 3000, x4000 Conf# 98413
    • FR/Paris: +33 1 84 88 37 37, x4000 Conf# 98413
    • Gmail Chat (requires Flash and the Google Talk plugin): paste +1 650 903 0800 into the Gmail Chat box that doesn't look like it accepts phone numbers
    • SkypeOut is free if you use the 800 number
  • WebAPI Vidyo Room / London-Allo Allo / Toronto-Spadina
  • Join irc.mozilla.org #webapi for back channel

Notes below archived from etherpad: https://etherpad.mozilla.org/webapi-meetingnotes


  • TV Tuner API: https://etherpad.mozilla.org/f8MAQgMbZH
    • Issue: which way to play the video/audio steam on a channel is better?
      • TV Tuner API will return MediaStream based on a channel, which can be set by the VideoElement to play.
        • the discussion seemed to conclude that this is better than the URI option below
      • TV Tuner API will return some tuner/channel specific information and apps needs to use them to generate URI for VideoElement to play.
        • dvb-t://...
        • av://...
        • hdmi://...
          • advantages: apps can generate such a URI and pass it to <video>
          • disadvantages:
            • <video> needs to know about the variety of schemas
            • having to limit <video> to be able to play certain schemas when it's running in a certified app vs not
            • new URI schemes have wide-ranging effects
            • WebRTC precedent of not using URIs (we should find out their reasons for doing so)
            • standardization will need to be done with external bodies (ex. IETF)
    • Issue: does it make sense to cover the Picture Information (e.g., brightness, contract, saturation... etc) and the Common Interface (i.e., a module is used to interface between the pay-to-view card and the TV) in the Settings API?
      • are these device-wide settings?
      • filters on top of <video> = no help necessary from platform (as long as we have ex. SVG filter implementations in hardware that are fast enough)
    • certified-only for the time being
    • concerns with proposed API
      • knowledge of currently-in-use tuner
      • is enough information exposed to support switching inputs on the TV ex. setSource or setTuner
      • managing inputs other than TV tuners (ex. something connected via HDMI)? use getUserMedia to get media stream
      • what happens when calling scan() on a TV Tuner object that is sending a stream to a <video> element?
    • project-wide concern: get various interested partners to work together as much as possible
    • Gene is going to confirm new APIs will only be certified-only
    • Gene is going to try to get desired timelines in all requests to mailing lists
  • hasFeature/getFeature proposal up on dev-webapi (current mailing list archiving is broken so hopefully interested parties are already subscribed)