WebAPI/2014-06-10

« previous week | index | next week »

WebAPI Meeting Details

• Tuesday 2014-06-10 - 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

Notes

jedp - intend to implement navigator.requestSync and .unregisterSync

• We intend to write an intend-to-implement email to dev-webapi and dev-platform
  • perfect. that is where the bulk of the discussion will happen (but it's great that we had the opportunity to discuss synchronously!)
  • [jed] done: https://groups.google.com/forum/#!topic/mozilla.dev.webapi/3LbVbgJgaIQ
• See: https://wiki.mozilla.org/Cloud_Services/FirefoxOS_Sync
• To implement: https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md
  • "tell an application when it's a good time to sync"
  • "alarm API + network status changes"
• Questions
  • any feedback on architecture of work in progress? https://bugzilla.mozilla.org/show_bug.cgi?id=1018320#c8
  • apart from implementing navigator.* in C++ (can't seem to add things to navigator object from JS), what else will we need to do in C++? (Exposing api to service worker through DOM?)
  • will we be able to implement scheduler in JS?
• question: why not use fetch in service workers?
  • assurances provided by system to app instead of relying on periodic sync
  • may also provide ability for system to protect against malicious/errant apps
• question: why are you trying to use system messages?
  • only a short-term goal until we have a shippable product
  • basically awaiting shipping Service Workers
  • there are partners needing an ability to wake themselves up and system messages achieve this for now
  • can't expose system messages to the web
• turning this into a spec?
  • annevk suggests emailing public-webapps with a formal proposal
• exposure?
  • UX for user approval of app's intention to sync data? "may affect battery life"
  • everything? when we move this away from system message wakeup mechanism, there will be an API change
    • which is concerning about exposing this to an ecosystem of developers we don't have direct influence over
  • when we're closer to landing this, let's re-evaluate moving to service workers, etc.
• concern: memory pressure + completion of a sync in a service worker?
• jedp: follow up with a list of apis we'll need in service workers and use cases
  • start a separate email thread on these