From MozillaWiki
Jump to: navigation, search

« previous week | index | next week »

WebAPI Meeting Details

  • Tuesday 2013-11-19 - 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


  • Apologies for midnight meeting time in Taipei ... we'll figure something out (7 AM in California? Jokes)
  • Telephony API and SysApps status
    • who's going to implement this outside of Mozilla? Intel? Samsung?
    • current status of API requires lots of work to implement/match
    • Marcos thinks there isn't large enough developer demand to justify the work we'd have to put in
    • Jonas cautions that since we aim to be a standards-based platform, we can't just drop the low priority things entirely
    • Vicamo and Hsinyi agree that in the future we want to update our telephony implementation to match the spec
    • certified-only API so what's the point of having an SIP backend, Jonas asks
      • coincidentally, ehsan and overholt were just discussing http://talkilla.mozillalabs.com/
      • Jonas thinks desktop backend isn't terribly interesting due to presence of WebRTC
    • "If I'm a developer" -- sicking
    • Vicamo suggests having a simple "call" API would be useful ... maybe Telephony would fit the bill?
    • integrate "call" via WebRTC and Telephony?
    • Jonas and Marcos think SIP or WebRTC backends aren't as useful
    • this will be a standard only if others implement it; action item 1: find out status of others implementations
    • agreement: implement good ideas from spec in our telephony stack (ex. promises), keep eye on other implementations
    • Hsinyi asks how much more work we should do with API design
      • Marcos notes that he's spent a lot of time on it already and there hasn't been a lot of progress since he stopped actively working on it
      • Jonas thinks we should encourage others to do work on it and watch progress
  • Replace Messaging/Contacts APIs by DataStore API
    • We used to have a con-call meeting with W3C editors in the last week and they're hoping don't let apps directly call DataStore API. Instead, Messaging API itself can have its own getMessage()/deleteMessage()/sync()... etc functions to do synchronization.
    • A very initiative draft: https://etherpad.mozilla.org/9MiQ4VWKSO
    • Thoughts? W3C editors are in a hurry to know our feedbacks because Messaging/Contacts APIs have been blocked by DataStore API for a while.
    • Jonas would like to see us move message db into DataStore (potentially expose to apps?)
    • Jonas thinks we should tell WG our plan:
      • we'll change Messaging to use DataStore eventually
      • we're not planning on implementing the current Messaging API as it stands today
      • we'll keep working on moving message DB into DataStore and build experience with it in preparation for standardization
      • we'll stop adding sync functions into Messaging API
    • as for DataStore itself, we should push to standardize it (at SysApps) once we have more experience with it and feel it's ready
  • https://wiki.mozilla.org/WebAPI/XHRBatch
    • feedback needed
  • New meeting time?
    • Andrew will work on this
  • API formerly known as Network Information API
    • Gene and Fernando both want to own
    • need to help them get going on standardization here
    • pretty high priority API for developers
    • state of the art on many platforms: expose "mobile network" (with bandwidth) vs. "wifi"
      • we should likely just expose type of connection and let people provide heuristics around payed connection since that's very difficult (impossible?) to know
      • just expose bandwidth on mobile connection (like _potential_ bandwidth?)
      • will likely get some pushback at W3C but could really help developers and users