Canmove, confirm
901
edits
Changes
Created page with "<!-- Maybe don't screw with these links unless you've read this blog post: http://blog.johnath.com/2011/01/20/automatic-date-links-in-mediawiki/ Just copy them to new pages an..."
<!-- Maybe don't screw with these links unless you've read this blog post:
http://blog.johnath.com/2011/01/20/automatic-date-links-in-mediawiki/
Just copy them to new pages and it should Just Work!
-->
<small>[[WebAPI/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous week]] | [[WebAPI|index]] | [[WebAPI/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]</small>
<div class="h-event vevent">
'''<span class="p-summary summary">WebAPI Meeting</span> Details'''
* <span class="dt-start dtstart">Tuesday <span class="value">{{#time: Y-m-d | {{SUBPAGENAME}} }}</span> - <span class="value">8:00</span> am <abbr class="value" title="-0700">Pacific</abbr></span>
{{conf|98413}}
* <span class="location">[https://v.mozilla.com/flex.html?roomdirect.html&key=H1q64MSinl9H WebAPI Vidyo Room] / London-Allo Allo / Toronto-Spadina</span>
* Join irc.mozilla.org [irc://irc.mozilla.org/webapi #webapi] for back channel
</div>
Notes below archived from etherpad: https://etherpad.mozilla.org/webapi-meetingnotes
== Notes ==
* Service Workers shindig in SF this week
** planning, hacking on fetch
** see https://etherpad.mozilla.org/swwork for ongoing plans
* Ehsan's intern Roshan Vid
** going to work on prerendering in FxOS and desktop \o/
* Web Activities
** W3C (DAP) is interested and it's in their charter
** from what we hear, Google and others are interested
** annevk is planning on beginning on this in August
* Special guests today
** David Bialer (Product Manager for apps, marketplace, etc.)
*** partner API requirements
** Ian Bicking (Engineering Manager in Cloud Services)
*** services requiring DOM APIs
** Myk Melez
*** interested in cross-platform APIs, notably a unified menubar API (like OS X or Unity menus, but unlikely to be of interested on desktop)
*** existing proposal to extend <menu> to use OS menu where possible
*** Myk thinks people are most interested in doing this in standalone (own window, own process, notably Android "ActionBar" (see below)) web apps, not in browser UAs
**** http://developer.android.com/guide/topics/ui/actionbar.html
*** Marcos cautions that the trend with web development has been to maintain unique experiences and avoid too much OS tie-in
*** Myk notes (and Marcos agrees) that there are use cases where native affordances would be useful for web apps; only 2 he knows of right now:
**** on desktop: menu bar
**** on android: action bar
* David B asked on marketplace-dev about having a single link to a web page / a packaged app and re-iterates his question here
** https://groups.google.com/forum/#!topic/mozilla.dev.marketplace/kpX6CyU87wg
** could an app register as a URL handler?
** since no JS possible in emails, have to use custom protocol
** navigator.registerProtocolHandler is possible but seems underused
*** https://developer.mozilla.org/en-US/docs/Web/API/navigator.registerProtocolHandler
** Jonas has a proposal
** Ehsan recommends a thread on dev-webapi since existing proposals and mechanisms likely don't solve the use case David brought up
* Ian notes that they've started another iteration on server side push stuff
http://blog.johnath.com/2011/01/20/automatic-date-links-in-mediawiki/
Just copy them to new pages and it should Just Work!
-->
<small>[[WebAPI/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous week]] | [[WebAPI|index]] | [[WebAPI/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]</small>
<div class="h-event vevent">
'''<span class="p-summary summary">WebAPI Meeting</span> Details'''
* <span class="dt-start dtstart">Tuesday <span class="value">{{#time: Y-m-d | {{SUBPAGENAME}} }}</span> - <span class="value">8:00</span> am <abbr class="value" title="-0700">Pacific</abbr></span>
{{conf|98413}}
* <span class="location">[https://v.mozilla.com/flex.html?roomdirect.html&key=H1q64MSinl9H WebAPI Vidyo Room] / London-Allo Allo / Toronto-Spadina</span>
* Join irc.mozilla.org [irc://irc.mozilla.org/webapi #webapi] for back channel
</div>
Notes below archived from etherpad: https://etherpad.mozilla.org/webapi-meetingnotes
== Notes ==
* Service Workers shindig in SF this week
** planning, hacking on fetch
** see https://etherpad.mozilla.org/swwork for ongoing plans
* Ehsan's intern Roshan Vid
** going to work on prerendering in FxOS and desktop \o/
* Web Activities
** W3C (DAP) is interested and it's in their charter
** from what we hear, Google and others are interested
** annevk is planning on beginning on this in August
* Special guests today
** David Bialer (Product Manager for apps, marketplace, etc.)
*** partner API requirements
** Ian Bicking (Engineering Manager in Cloud Services)
*** services requiring DOM APIs
** Myk Melez
*** interested in cross-platform APIs, notably a unified menubar API (like OS X or Unity menus, but unlikely to be of interested on desktop)
*** existing proposal to extend <menu> to use OS menu where possible
*** Myk thinks people are most interested in doing this in standalone (own window, own process, notably Android "ActionBar" (see below)) web apps, not in browser UAs
**** http://developer.android.com/guide/topics/ui/actionbar.html
*** Marcos cautions that the trend with web development has been to maintain unique experiences and avoid too much OS tie-in
*** Myk notes (and Marcos agrees) that there are use cases where native affordances would be useful for web apps; only 2 he knows of right now:
**** on desktop: menu bar
**** on android: action bar
* David B asked on marketplace-dev about having a single link to a web page / a packaged app and re-iterates his question here
** https://groups.google.com/forum/#!topic/mozilla.dev.marketplace/kpX6CyU87wg
** could an app register as a URL handler?
** since no JS possible in emails, have to use custom protocol
** navigator.registerProtocolHandler is possible but seems underused
*** https://developer.mozilla.org/en-US/docs/Web/API/navigator.registerProtocolHandler
** Jonas has a proposal
** Ehsan recommends a thread on dev-webapi since existing proposals and mechanisms likely don't solve the use case David brought up
* Ian notes that they've started another iteration on server side push stuff
