Re: WebView Promise and W3C standards

[Andrew Grieve]

I believe there's not API to insert this early for Android / iOS other than
in the new WKWebView.

On Thu, Dec 11, 2014 at 3:23 PM, Jesse purplecabb...@gmail.com wrote:

 The native side knows the browser capabilities long before it's
 loaded, or even created, compile time even. They will never change
 after the app is built.
 On WP8 the scripts are injected right before DOMContentLoaded fires,
 and before any js code in the page is run.  I realize other platforms
 may not be able to catch the browser load events early enough to be
 effective though. Anyone know the native side event flow for
 iOS+Android?

  On Dec 11, 2014, at 10:54 AM, Andrew Grieve agri...@chromium.org
 wrote:
 
  Let's start a new thread for browserify.
 
  Jesse - def. like the idea of injecting polyfills when they are not there
  but are required. In practice though, I think it ends up pretty much the
  same anyways:
  - On start-up you need to feature-detect Promise via JS
  - If it's not there, you need to inject it.
 
  Whether the injection occurs via the native side shoving it in, or by
  cordova.js require()'ing a module is a matter of whether we check in
  es6-promise.js into each platform separately, or into cordova-js.
 
 
  On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:
 
  we should move browserify to main and drop that insane concat code
 
  its not heavyweight at all. it creates a hash in iife with deps mapped
  in…as to why dep mgmt is better than concatenating…I don't think we
 need to
  waste our time talking about that!
 
  On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
  There's something implemented behind a --browserify flag, but not sure
  what
  it does.
 
  Totally in favour of having CLI / plugman concatenate plugin JS with
  cordova.js, but not convinced that browserify is the right tool for
 this,
  as it seems quite heavy-weight for just concatenating things. If
 someone
  is
  going to resume work on it, would love to hear a summary of what
 problems
  it's solving (if more than concatenation), and why something more
  light-weight wouldn't be better.
 
  On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
  We haven't worked on it, also curious.  Anis, perhaps?
 
  On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:
 
  def think we should support those specs in our great and fabled api
  audit…had not considered the load order issue
 
  not insurmountable and probably should be a feature/fix for the
  plugin
  loader load order …but also sort of scary… reminds me of script tags
  hell
 
  on that note: we need to make browserify thing first class. whats the
  hold
  up on that front?
 
  On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
  Do we prefer to invent new cordova-specific apis, or prefer to
  match
  standard browser apis?  When there is no browser spec to match then
  design
  comes down to aesthetics and personal preference (as you say).  But
  often
  there is an existing browser spec, and then it comes down to match
  or
  fork.  I'm in the camp of preferring to match, and was under the
  assumption
  others here were too.
 
  Given the upcoming specs mentioned earlier (sockets, file,
  filesystem,
  permissions, service worker, fetch), seems that fighting the
  adoption
  of
  promises in core apis implies opposing the adoption of modern web
  specs.
  e.g. I'm assuming Andrew was referring to
  http://www.w3.org/TR/battery-status/, since matching that spec
  *would*
  require promises.
 
 
  Now, as I understand, you are not saying you are opposed to
  adoption
  of
  promises in Cordova, but that you are simply against the inclusion
  of a
  polyfill directly inside cordova-js.  I think that a
  promises-polyfill
  plugin alternative has some technical downsides [1], but they seem
  not
  so
  insurmountable that we shouldn't just get passed this debate and do
  that.
 
  In my opinion, we should prefer to create a common plugin (at least
  until
  browserify), since I really hope we don't tell devs to just include
  their
  own polyfill with each plugin.
 
  [1]:
  - Can't rely on a polyfill plugin for cordova-js itself.  There
  are a
  few
  places where that may have been useful.
  - We don't currently load plugins in an order that respects plugin
  dependencies, so every plugin relying on promises-polyfill will
  have
  to
  require() it at runtime before using  and forgetting to do so
  may-or-may-not lead to an error.  Maybe we just fix this in our
  plugin
  loader.
  - It seems odd that window.Promise will exist depending on which
  plugins
  you have installed.  While this technically isn't different than
  with
  any
  plugin modifying global symbols, it seems odd-er when applied to a
  dependant platform feature.
 
  -Michal
 
  On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com
  wrote:
 
  Why does battery-status 'require' promises?
 
  I 

Re: WebView Promise and W3C standards

[Shazron]

Yup, WKWebView has an option to add a script at
WKUserScriptInjectionTimeAtDocumentStart.

On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve agri...@chromium.org wrote:
 I believe there's not API to insert this early for Android / iOS other than
 in the new WKWebView.

 On Thu, Dec 11, 2014 at 3:23 PM, Jesse purplecabb...@gmail.com wrote:

 The native side knows the browser capabilities long before it's
 loaded, or even created, compile time even. They will never change
 after the app is built.
 On WP8 the scripts are injected right before DOMContentLoaded fires,
 and before any js code in the page is run.  I realize other platforms
 may not be able to catch the browser load events early enough to be
 effective though. Anyone know the native side event flow for
 iOS+Android?

  On Dec 11, 2014, at 10:54 AM, Andrew Grieve agri...@chromium.org
 wrote:
 
  Let's start a new thread for browserify.
 
  Jesse - def. like the idea of injecting polyfills when they are not there
  but are required. In practice though, I think it ends up pretty much the
  same anyways:
  - On start-up you need to feature-detect Promise via JS
  - If it's not there, you need to inject it.
 
  Whether the injection occurs via the native side shoving it in, or by
  cordova.js require()'ing a module is a matter of whether we check in
  es6-promise.js into each platform separately, or into cordova-js.
 
 
  On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:
 
  we should move browserify to main and drop that insane concat code
 
  its not heavyweight at all. it creates a hash in iife with deps mapped
  in…as to why dep mgmt is better than concatenating…I don't think we
 need to
  waste our time talking about that!
 
  On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
  There's something implemented behind a --browserify flag, but not sure
  what
  it does.
 
  Totally in favour of having CLI / plugman concatenate plugin JS with
  cordova.js, but not convinced that browserify is the right tool for
 this,
  as it seems quite heavy-weight for just concatenating things. If
 someone
  is
  going to resume work on it, would love to hear a summary of what
 problems
  it's solving (if more than concatenation), and why something more
  light-weight wouldn't be better.
 
  On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
  We haven't worked on it, also curious.  Anis, perhaps?
 
  On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:
 
  def think we should support those specs in our great and fabled api
  audit…had not considered the load order issue
 
  not insurmountable and probably should be a feature/fix for the
  plugin
  loader load order …but also sort of scary… reminds me of script tags
  hell
 
  on that note: we need to make browserify thing first class. whats the
  hold
  up on that front?
 
  On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
  Do we prefer to invent new cordova-specific apis, or prefer to
  match
  standard browser apis?  When there is no browser spec to match then
  design
  comes down to aesthetics and personal preference (as you say).  But
  often
  there is an existing browser spec, and then it comes down to match
  or
  fork.  I'm in the camp of preferring to match, and was under the
  assumption
  others here were too.
 
  Given the upcoming specs mentioned earlier (sockets, file,
  filesystem,
  permissions, service worker, fetch), seems that fighting the
  adoption
  of
  promises in core apis implies opposing the adoption of modern web
  specs.
  e.g. I'm assuming Andrew was referring to
  http://www.w3.org/TR/battery-status/, since matching that spec
  *would*
  require promises.
 
 
  Now, as I understand, you are not saying you are opposed to
  adoption
  of
  promises in Cordova, but that you are simply against the inclusion
  of a
  polyfill directly inside cordova-js.  I think that a
  promises-polyfill
  plugin alternative has some technical downsides [1], but they seem
  not
  so
  insurmountable that we shouldn't just get passed this debate and do
  that.
 
  In my opinion, we should prefer to create a common plugin (at least
  until
  browserify), since I really hope we don't tell devs to just include
  their
  own polyfill with each plugin.
 
  [1]:
  - Can't rely on a polyfill plugin for cordova-js itself.  There
  are a
  few
  places where that may have been useful.
  - We don't currently load plugins in an order that respects plugin
  dependencies, so every plugin relying on promises-polyfill will
  have
  to
  require() it at runtime before using  and forgetting to do so
  may-or-may-not lead to an error.  Maybe we just fix this in our
  plugin
  loader.
  - It seems odd that window.Promise will exist depending on which
  plugins
  you have installed.  While this technically isn't different than
  with
  any
  plugin modifying global symbols, it seems odd-er when applied to a
  

Re: WebView Promise and W3C standards

[Jesse]

On Fri, Dec 12, 2014 at 11:10 AM, Shazron shaz...@gmail.com wrote:

 Yup, WKWebView has an option to add a script at
 WKUserScriptInjectionTimeAtDocumentStart.

 On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve agri...@chromium.org
 wrote:
  I believe there's not API to insert this early for Android / iOS other
 than
  in the new WKWebView.


On iOS you can inject js code in webViewDidStartLoad, which is evaluated
and available before any other js loads/runs. Science before belief.
I will run a similar test on Android.



 
  On Thu, Dec 11, 2014 at 3:23 PM, Jesse purplecabb...@gmail.com wrote:
 
  The native side knows the browser capabilities long before it's
  loaded, or even created, compile time even. They will never change
  after the app is built.
  On WP8 the scripts are injected right before DOMContentLoaded fires,
  and before any js code in the page is run.  I realize other platforms
  may not be able to catch the browser load events early enough to be
  effective though. Anyone know the native side event flow for
  iOS+Android?
 
   On Dec 11, 2014, at 10:54 AM, Andrew Grieve agri...@chromium.org
  wrote:
  
   Let's start a new thread for browserify.
  
   Jesse - def. like the idea of injecting polyfills when they are not
 there
   but are required. In practice though, I think it ends up pretty much
 the
   same anyways:
   - On start-up you need to feature-detect Promise via JS
   - If it's not there, you need to inject it.
  
   Whether the injection occurs via the native side shoving it in, or by
   cordova.js require()'ing a module is a matter of whether we check in
   es6-promise.js into each platform separately, or into cordova-js.
  
  
   On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:
  
   we should move browserify to main and drop that insane concat code
  
   its not heavyweight at all. it creates a hash in iife with deps
 mapped
   in…as to why dep mgmt is better than concatenating…I don't think we
  need to
   waste our time talking about that!
  
   On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve agri...@chromium.org
 
   wrote:
  
   There's something implemented behind a --browserify flag, but not
 sure
   what
   it does.
  
   Totally in favour of having CLI / plugman concatenate plugin JS with
   cordova.js, but not convinced that browserify is the right tool for
  this,
   as it seems quite heavy-weight for just concatenating things. If
  someone
   is
   going to resume work on it, would love to hear a summary of what
  problems
   it's solving (if more than concatenation), and why something more
   light-weight wouldn't be better.
  
   On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny mmo...@chromium.org
 
   wrote:
  
   We haven't worked on it, also curious.  Anis, perhaps?
  
   On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:
  
   def think we should support those specs in our great and fabled
 api
   audit…had not considered the load order issue
  
   not insurmountable and probably should be a feature/fix for the
   plugin
   loader load order …but also sort of scary… reminds me of script
 tags
   hell
  
   on that note: we need to make browserify thing first class. whats
 the
   hold
   up on that front?
  
   On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny 
 mmo...@chromium.org
   wrote:
  
   Do we prefer to invent new cordova-specific apis, or prefer to
   match
   standard browser apis?  When there is no browser spec to match
 then
   design
   comes down to aesthetics and personal preference (as you say).
 But
   often
   there is an existing browser spec, and then it comes down to
 match
   or
   fork.  I'm in the camp of preferring to match, and was under the
   assumption
   others here were too.
  
   Given the upcoming specs mentioned earlier (sockets, file,
   filesystem,
   permissions, service worker, fetch), seems that fighting the
   adoption
   of
   promises in core apis implies opposing the adoption of modern web
   specs.
   e.g. I'm assuming Andrew was referring to
   http://www.w3.org/TR/battery-status/, since matching that spec
   *would*
   require promises.
  
  
   Now, as I understand, you are not saying you are opposed to
   adoption
   of
   promises in Cordova, but that you are simply against the
 inclusion
   of a
   polyfill directly inside cordova-js.  I think that a
   promises-polyfill
   plugin alternative has some technical downsides [1], but they
 seem
   not
   so
   insurmountable that we shouldn't just get passed this debate and
 do
   that.
  
   In my opinion, we should prefer to create a common plugin (at
 least
   until
   browserify), since I really hope we don't tell devs to just
 include
   their
   own polyfill with each plugin.
  
   [1]:
   - Can't rely on a polyfill plugin for cordova-js itself.  There
   are a
   few
   places where that may have been useful.
   - We don't currently load plugins in an order that respects
 plugin
   dependencies, so every plugin relying on 

Re: WebView Promise and W3C standards

[Andrew Grieve]

On Fri, Dec 12, 2014 at 2:28 PM, Jesse purplecabb...@gmail.com wrote:

 On Fri, Dec 12, 2014 at 11:10 AM, Shazron shaz...@gmail.com wrote:

  Yup, WKWebView has an option to add a script at
  WKUserScriptInjectionTimeAtDocumentStart.
 
  On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve agri...@chromium.org
  wrote:
   I believe there's not API to insert this early for Android / iOS other
  than
   in the new WKWebView.
 

 On iOS you can inject js code in webViewDidStartLoad, which is evaluated
 and available before any other js loads/runs. Science before belief.
 I will run a similar test on Android.

This is sadly not the case. You're still in the context of the previous
page when this is fired.






  
   On Thu, Dec 11, 2014 at 3:23 PM, Jesse purplecabb...@gmail.com
 wrote:
  
   The native side knows the browser capabilities long before it's
   loaded, or even created, compile time even. They will never change
   after the app is built.
   On WP8 the scripts are injected right before DOMContentLoaded fires,
   and before any js code in the page is run.  I realize other platforms
   may not be able to catch the browser load events early enough to be
   effective though. Anyone know the native side event flow for
   iOS+Android?
  
On Dec 11, 2014, at 10:54 AM, Andrew Grieve agri...@chromium.org
   wrote:
   
Let's start a new thread for browserify.
   
Jesse - def. like the idea of injecting polyfills when they are not
  there
but are required. In practice though, I think it ends up pretty much
  the
same anyways:
- On start-up you need to feature-detect Promise via JS
- If it's not there, you need to inject it.
   
Whether the injection occurs via the native side shoving it in, or
 by
cordova.js require()'ing a module is a matter of whether we check in
es6-promise.js into each platform separately, or into cordova-js.
   
   
On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:
   
we should move browserify to main and drop that insane concat code
   
its not heavyweight at all. it creates a hash in iife with deps
  mapped
in…as to why dep mgmt is better than concatenating…I don't think we
   need to
waste our time talking about that!
   
On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve 
 agri...@chromium.org
  
wrote:
   
There's something implemented behind a --browserify flag, but not
  sure
what
it does.
   
Totally in favour of having CLI / plugman concatenate plugin JS
 with
cordova.js, but not convinced that browserify is the right tool
 for
   this,
as it seems quite heavy-weight for just concatenating things. If
   someone
is
going to resume work on it, would love to hear a summary of what
   problems
it's solving (if more than concatenation), and why something more
light-weight wouldn't be better.
   
On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny 
 mmo...@chromium.org
  
wrote:
   
We haven't worked on it, also curious.  Anis, perhaps?
   
On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io
 wrote:
   
def think we should support those specs in our great and fabled
  api
audit…had not considered the load order issue
   
not insurmountable and probably should be a feature/fix for the
plugin
loader load order …but also sort of scary… reminds me of script
  tags
hell
   
on that note: we need to make browserify thing first class.
 whats
  the
hold
up on that front?
   
On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny 
  mmo...@chromium.org
wrote:
   
Do we prefer to invent new cordova-specific apis, or prefer to
match
standard browser apis?  When there is no browser spec to match
  then
design
comes down to aesthetics and personal preference (as you say).
  But
often
there is an existing browser spec, and then it comes down to
  match
or
fork.  I'm in the camp of preferring to match, and was under
 the
assumption
others here were too.
   
Given the upcoming specs mentioned earlier (sockets, file,
filesystem,
permissions, service worker, fetch), seems that fighting the
adoption
of
promises in core apis implies opposing the adoption of modern
 web
specs.
e.g. I'm assuming Andrew was referring to
http://www.w3.org/TR/battery-status/, since matching that spec
*would*
require promises.
   
   
Now, as I understand, you are not saying you are opposed to
adoption
of
promises in Cordova, but that you are simply against the
  inclusion
of a
polyfill directly inside cordova-js.  I think that a
promises-polyfill
plugin alternative has some technical downsides [1], but they
  seem
not
so
insurmountable that we shouldn't just get passed this debate
 and
  do
that.
   
In my opinion, we should prefer to create a common plugin (at
  least
until
browserify), since I really hope we 

Re: WebView Promise and W3C standards

[Jesse]

Oops, I was wrong.  My test works on the first page loaded, but any page after 
that it does not. Your faith was well placed. I won't bother trying Android, as 
no-iOS is a blocker. 



 On Dec 12, 2014, at 11:55 AM, Andrew Grieve agri...@chromium.org wrote:
 
 On Fri, Dec 12, 2014 at 2:28 PM, Jesse purplecabb...@gmail.com wrote:
 
 On Fri, Dec 12, 2014 at 11:10 AM, Shazron shaz...@gmail.com wrote:
 
 Yup, WKWebView has an option to add a script at
 WKUserScriptInjectionTimeAtDocumentStart.
 
 On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve agri...@chromium.org
 wrote:
 I believe there's not API to insert this early for Android / iOS other
 than
 in the new WKWebView.
 
 On iOS you can inject js code in webViewDidStartLoad, which is evaluated
 and available before any other js loads/runs. Science before belief.
 I will run a similar test on Android.
 This is sadly not the case. You're still in the context of the previous
 page when this is fired.
 
 
 
 
 
 
 
 On Thu, Dec 11, 2014 at 3:23 PM, Jesse purplecabb...@gmail.com
 wrote:
 
 The native side knows the browser capabilities long before it's
 loaded, or even created, compile time even. They will never change
 after the app is built.
 On WP8 the scripts are injected right before DOMContentLoaded fires,
 and before any js code in the page is run.  I realize other platforms
 may not be able to catch the browser load events early enough to be
 effective though. Anyone know the native side event flow for
 iOS+Android?
 
 On Dec 11, 2014, at 10:54 AM, Andrew Grieve agri...@chromium.org
 wrote:
 
 Let's start a new thread for browserify.
 
 Jesse - def. like the idea of injecting polyfills when they are not
 there
 but are required. In practice though, I think it ends up pretty much
 the
 same anyways:
 - On start-up you need to feature-detect Promise via JS
 - If it's not there, you need to inject it.
 
 Whether the injection occurs via the native side shoving it in, or
 by
 cordova.js require()'ing a module is a matter of whether we check in
 es6-promise.js into each platform separately, or into cordova-js.
 
 
 On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:
 
 we should move browserify to main and drop that insane concat code
 
 its not heavyweight at all. it creates a hash in iife with deps
 mapped
 in…as to why dep mgmt is better than concatenating…I don't think we
 need to
 waste our time talking about that!
 
 On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve 
 agri...@chromium.org
 
 wrote:
 
 There's something implemented behind a --browserify flag, but not
 sure
 what
 it does.
 
 Totally in favour of having CLI / plugman concatenate plugin JS
 with
 cordova.js, but not convinced that browserify is the right tool
 for
 this,
 as it seems quite heavy-weight for just concatenating things. If
 someone
 is
 going to resume work on it, would love to hear a summary of what
 problems
 it's solving (if more than concatenation), and why something more
 light-weight wouldn't be better.
 
 On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny 
 mmo...@chromium.org
 
 wrote:
 
 We haven't worked on it, also curious.  Anis, perhaps?
 
 On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io
 wrote:
 
 def think we should support those specs in our great and fabled
 api
 audit…had not considered the load order issue
 
 not insurmountable and probably should be a feature/fix for the
 plugin
 loader load order …but also sort of scary… reminds me of script
 tags
 hell
 
 on that note: we need to make browserify thing first class.
 whats
 the
 hold
 up on that front?
 
 On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny 
 mmo...@chromium.org
 wrote:
 
 Do we prefer to invent new cordova-specific apis, or prefer to
 match
 standard browser apis?  When there is no browser spec to match
 then
 design
 comes down to aesthetics and personal preference (as you say).
 But
 often
 there is an existing browser spec, and then it comes down to
 match
 or
 fork.  I'm in the camp of preferring to match, and was under
 the
 assumption
 others here were too.
 
 Given the upcoming specs mentioned earlier (sockets, file,
 filesystem,
 permissions, service worker, fetch), seems that fighting the
 adoption
 of
 promises in core apis implies opposing the adoption of modern
 web
 specs.
 e.g. I'm assuming Andrew was referring to
 http://www.w3.org/TR/battery-status/, since matching that spec
 *would*
 require promises.
 
 
 Now, as I understand, you are not saying you are opposed to
 adoption
 of
 promises in Cordova, but that you are simply against the
 inclusion
 of a
 polyfill directly inside cordova-js.  I think that a
 promises-polyfill
 plugin alternative has some technical downsides [1], but they
 seem
 not
 so
 insurmountable that we shouldn't just get passed this debate
 and
 do
 that.
 
 In my opinion, we should prefer to create a common plugin (at
 least
 until
 browserify), since I really hope we don't tell devs to just
 include
 their
 own polyfill with each 

Re: WebView Promise and W3C standards

[Brian LeRoux]

you could do sneakier haicker things …at any rate -1 on promises remains
the case

On Fri, Dec 12, 2014 at 12:25 PM, Jesse purplecabb...@gmail.com wrote:

 Oops, I was wrong.  My test works on the first page loaded, but any page
 after that it does not. Your faith was well placed. I won't bother trying
 Android, as no-iOS is a blocker.



  On Dec 12, 2014, at 11:55 AM, Andrew Grieve agri...@chromium.org
 wrote:
 
  On Fri, Dec 12, 2014 at 2:28 PM, Jesse purplecabb...@gmail.com wrote:
 
  On Fri, Dec 12, 2014 at 11:10 AM, Shazron shaz...@gmail.com wrote:
 
  Yup, WKWebView has an option to add a script at
  WKUserScriptInjectionTimeAtDocumentStart.
 
  On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve agri...@chromium.org
  wrote:
  I believe there's not API to insert this early for Android / iOS other
  than
  in the new WKWebView.
 
  On iOS you can inject js code in webViewDidStartLoad, which is evaluated
  and available before any other js loads/runs. Science before belief.
  I will run a similar test on Android.
  This is sadly not the case. You're still in the context of the previous
  page when this is fired.
 
 
 
 
 
 
 
  On Thu, Dec 11, 2014 at 3:23 PM, Jesse purplecabb...@gmail.com
  wrote:
 
  The native side knows the browser capabilities long before it's
  loaded, or even created, compile time even. They will never change
  after the app is built.
  On WP8 the scripts are injected right before DOMContentLoaded fires,
  and before any js code in the page is run.  I realize other platforms
  may not be able to catch the browser load events early enough to be
  effective though. Anyone know the native side event flow for
  iOS+Android?
 
  On Dec 11, 2014, at 10:54 AM, Andrew Grieve agri...@chromium.org
  wrote:
 
  Let's start a new thread for browserify.
 
  Jesse - def. like the idea of injecting polyfills when they are not
  there
  but are required. In practice though, I think it ends up pretty much
  the
  same anyways:
  - On start-up you need to feature-detect Promise via JS
  - If it's not there, you need to inject it.
 
  Whether the injection occurs via the native side shoving it in, or
  by
  cordova.js require()'ing a module is a matter of whether we check in
  es6-promise.js into each platform separately, or into cordova-js.
 
 
  On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:
 
  we should move browserify to main and drop that insane concat code
 
  its not heavyweight at all. it creates a hash in iife with deps
  mapped
  in…as to why dep mgmt is better than concatenating…I don't think we
  need to
  waste our time talking about that!
 
  On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve 
  agri...@chromium.org
 
  wrote:
 
  There's something implemented behind a --browserify flag, but not
  sure
  what
  it does.
 
  Totally in favour of having CLI / plugman concatenate plugin JS
  with
  cordova.js, but not convinced that browserify is the right tool
  for
  this,
  as it seems quite heavy-weight for just concatenating things. If
  someone
  is
  going to resume work on it, would love to hear a summary of what
  problems
  it's solving (if more than concatenation), and why something more
  light-weight wouldn't be better.
 
  On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny 
  mmo...@chromium.org
 
  wrote:
 
  We haven't worked on it, also curious.  Anis, perhaps?
 
  On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io
  wrote:
 
  def think we should support those specs in our great and fabled
  api
  audit…had not considered the load order issue
 
  not insurmountable and probably should be a feature/fix for the
  plugin
  loader load order …but also sort of scary… reminds me of script
  tags
  hell
 
  on that note: we need to make browserify thing first class.
  whats
  the
  hold
  up on that front?
 
  On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny 
  mmo...@chromium.org
  wrote:
 
  Do we prefer to invent new cordova-specific apis, or prefer to
  match
  standard browser apis?  When there is no browser spec to match
  then
  design
  comes down to aesthetics and personal preference (as you say).
  But
  often
  there is an existing browser spec, and then it comes down to
  match
  or
  fork.  I'm in the camp of preferring to match, and was under
  the
  assumption
  others here were too.
 
  Given the upcoming specs mentioned earlier (sockets, file,
  filesystem,
  permissions, service worker, fetch), seems that fighting the
  adoption
  of
  promises in core apis implies opposing the adoption of modern
  web
  specs.
  e.g. I'm assuming Andrew was referring to
  http://www.w3.org/TR/battery-status/, since matching that spec
  *would*
  require promises.
 
 
  Now, as I understand, you are not saying you are opposed to
  adoption
  of
  promises in Cordova, but that you are simply against the
  inclusion
  of a
  polyfill directly inside cordova-js.  I think that a
  promises-polyfill
  plugin alternative has some technical downsides [1], but they
 

Re: WebView Promise and W3C standards

[Sebastien Blanc]

Just to let you know we have been using a promises polyfill plugin for some
time now : https://github.com/vstirbu/PromisesPlugin


On Thu, Dec 11, 2014 at 3:38 AM, Michal Mocny mmo...@chromium.org wrote:

 Jesse: yes, that could work.  By setting your polyfill to runs/ you'll be
 sure it is available after pluginsready (and thus deviceready).  For
 plugins that use Promises during bootstrap, which is unlikely to be common,
 the explicit require() on the polyfill is still an option.

 Regarding your Native injection suggestion: how early on in the boot
 process can we do this?  i.e. do you modify the startPage to inject this
 before loading cordova.js, or do you do it in response to an exec bridge
 call, making the timing about equivalent to the js polyfill?

 -Michal

 On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:

  we should move browserify to main and drop that insane concat code
 
  its not heavyweight at all. it creates a hash in iife with deps mapped
  in…as to why dep mgmt is better than concatenating…I don't think we need
 to
  waste our time talking about that!
 
  On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   There's something implemented behind a --browserify flag, but not sure
  what
   it does.
  
   Totally in favour of having CLI / plugman concatenate plugin JS with
   cordova.js, but not convinced that browserify is the right tool for
 this,
   as it seems quite heavy-weight for just concatenating things. If
 someone
  is
   going to resume work on it, would love to hear a summary of what
 problems
   it's solving (if more than concatenation), and why something more
   light-weight wouldn't be better.
  
   On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny mmo...@chromium.org
  wrote:
  
We haven't worked on it, also curious.  Anis, perhaps?
   
On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:
   
 def think we should support those specs in our great and fabled api
 audit…had not considered the load order issue

 not insurmountable and probably should be a feature/fix for the
  plugin
 loader load order …but also sort of scary… reminds me of script
 tags
   hell

 on that note: we need to make browserify thing first class. whats
 the
hold
 up on that front?

 On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny 
 mmo...@chromium.org
 wrote:

  Do we prefer to invent new cordova-specific apis, or prefer to
  match
  standard browser apis?  When there is no browser spec to match
 then
 design
  comes down to aesthetics and personal preference (as you say).
 But
often
  there is an existing browser spec, and then it comes down to
 match
  or
  fork.  I'm in the camp of preferring to match, and was under the
 assumption
  others here were too.
 
  Given the upcoming specs mentioned earlier (sockets, file,
   filesystem,
  permissions, service worker, fetch), seems that fighting the
  adoption
of
  promises in core apis implies opposing the adoption of modern web
specs.
   e.g. I'm assuming Andrew was referring to
  http://www.w3.org/TR/battery-status/, since matching that spec
   *would*
  require promises.
 
 
  Now, as I understand, you are not saying you are opposed to
  adoption
   of
  promises in Cordova, but that you are simply against the
 inclusion
   of a
  polyfill directly inside cordova-js.  I think that a
   promises-polyfill
  plugin alternative has some technical downsides [1], but they
 seem
   not
so
  insurmountable that we shouldn't just get passed this debate and
 do
that.
 
  In my opinion, we should prefer to create a common plugin (at
 least
until
  browserify), since I really hope we don't tell devs to just
 include
their
  own polyfill with each plugin.
 
  [1]:
  - Can't rely on a polyfill plugin for cordova-js itself.  There
  are a
few
  places where that may have been useful.
  - We don't currently load plugins in an order that respects
 plugin
  dependencies, so every plugin relying on promises-polyfill will
  have
   to
  require() it at runtime before using  and forgetting to do so
  may-or-may-not lead to an error.  Maybe we just fix this in our
   plugin
  loader.
  - It seems odd that window.Promise will exist depending on which
plugins
  you have installed.  While this technically isn't different than
  with
any
  plugin modifying global symbols, it seems odd-er when applied to
 a
  dependant platform feature.
 
  -Michal
 
  On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com
wrote:
 
   Why does battery-status 'require' promises?
  
   I agree that promises are here to stay, but I am unclear why it
   would
 be
  a
   good idea to go and change/rewrite/break our apis to use them?
   

Re: WebView Promise and W3C standards

[Andrew Grieve]

Let's start a new thread for browserify.

Jesse - def. like the idea of injecting polyfills when they are not there
but are required. In practice though, I think it ends up pretty much the
same anyways:
- On start-up you need to feature-detect Promise via JS
- If it's not there, you need to inject it.

Whether the injection occurs via the native side shoving it in, or by
cordova.js require()'ing a module is a matter of whether we check in
es6-promise.js into each platform separately, or into cordova-js.


On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:

 we should move browserify to main and drop that insane concat code

 its not heavyweight at all. it creates a hash in iife with deps mapped
 in…as to why dep mgmt is better than concatenating…I don't think we need to
 waste our time talking about that!

 On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve agri...@chromium.org
 wrote:

  There's something implemented behind a --browserify flag, but not sure
 what
  it does.
 
  Totally in favour of having CLI / plugman concatenate plugin JS with
  cordova.js, but not convinced that browserify is the right tool for this,
  as it seems quite heavy-weight for just concatenating things. If someone
 is
  going to resume work on it, would love to hear a summary of what problems
  it's solving (if more than concatenation), and why something more
  light-weight wouldn't be better.
 
  On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
   We haven't worked on it, also curious.  Anis, perhaps?
  
   On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:
  
def think we should support those specs in our great and fabled api
audit…had not considered the load order issue
   
not insurmountable and probably should be a feature/fix for the
 plugin
loader load order …but also sort of scary… reminds me of script tags
  hell
   
on that note: we need to make browserify thing first class. whats the
   hold
up on that front?
   
On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org
wrote:
   
 Do we prefer to invent new cordova-specific apis, or prefer to
 match
 standard browser apis?  When there is no browser spec to match then
design
 comes down to aesthetics and personal preference (as you say).  But
   often
 there is an existing browser spec, and then it comes down to match
 or
 fork.  I'm in the camp of preferring to match, and was under the
assumption
 others here were too.

 Given the upcoming specs mentioned earlier (sockets, file,
  filesystem,
 permissions, service worker, fetch), seems that fighting the
 adoption
   of
 promises in core apis implies opposing the adoption of modern web
   specs.
  e.g. I'm assuming Andrew was referring to
 http://www.w3.org/TR/battery-status/, since matching that spec
  *would*
 require promises.


 Now, as I understand, you are not saying you are opposed to
 adoption
  of
 promises in Cordova, but that you are simply against the inclusion
  of a
 polyfill directly inside cordova-js.  I think that a
  promises-polyfill
 plugin alternative has some technical downsides [1], but they seem
  not
   so
 insurmountable that we shouldn't just get passed this debate and do
   that.

 In my opinion, we should prefer to create a common plugin (at least
   until
 browserify), since I really hope we don't tell devs to just include
   their
 own polyfill with each plugin.

 [1]:
 - Can't rely on a polyfill plugin for cordova-js itself.  There
 are a
   few
 places where that may have been useful.
 - We don't currently load plugins in an order that respects plugin
 dependencies, so every plugin relying on promises-polyfill will
 have
  to
 require() it at runtime before using  and forgetting to do so
 may-or-may-not lead to an error.  Maybe we just fix this in our
  plugin
 loader.
 - It seems odd that window.Promise will exist depending on which
   plugins
 you have installed.  While this technically isn't different than
 with
   any
 plugin modifying global symbols, it seems odd-er when applied to a
 dependant platform feature.

 -Michal

 On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com
   wrote:

  Why does battery-status 'require' promises?
 
  I agree that promises are here to stay, but I am unclear why it
  would
be
 a
  good idea to go and change/rewrite/break our apis to use them?
 
  Most of the windows plugins use promises all over the place, the
   entire
  async windows js api is promise based, but this has zero impact
 on
   what
 our
  core-api looks like to a user. The same should apply to any
 plugin
   that
  wants to depend on promises, just depend on a promise plugin,
 which
   may
 or
  may not add polyfil code to the dom.
 
 

Re: WebView Promise and W3C standards

[Jesse]

The native side knows the browser capabilities long before it's
loaded, or even created, compile time even. They will never change
after the app is built.
On WP8 the scripts are injected right before DOMContentLoaded fires,
and before any js code in the page is run.  I realize other platforms
may not be able to catch the browser load events early enough to be
effective though. Anyone know the native side event flow for
iOS+Android?

 On Dec 11, 2014, at 10:54 AM, Andrew Grieve agri...@chromium.org wrote:

 Let's start a new thread for browserify.

 Jesse - def. like the idea of injecting polyfills when they are not there
 but are required. In practice though, I think it ends up pretty much the
 same anyways:
 - On start-up you need to feature-detect Promise via JS
 - If it's not there, you need to inject it.

 Whether the injection occurs via the native side shoving it in, or by
 cordova.js require()'ing a module is a matter of whether we check in
 es6-promise.js into each platform separately, or into cordova-js.


 On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:

 we should move browserify to main and drop that insane concat code

 its not heavyweight at all. it creates a hash in iife with deps mapped
 in…as to why dep mgmt is better than concatenating…I don't think we need to
 waste our time talking about that!

 On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve agri...@chromium.org
 wrote:

 There's something implemented behind a --browserify flag, but not sure
 what
 it does.

 Totally in favour of having CLI / plugman concatenate plugin JS with
 cordova.js, but not convinced that browserify is the right tool for this,
 as it seems quite heavy-weight for just concatenating things. If someone
 is
 going to resume work on it, would love to hear a summary of what problems
 it's solving (if more than concatenation), and why something more
 light-weight wouldn't be better.

 On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny mmo...@chromium.org
 wrote:

 We haven't worked on it, also curious.  Anis, perhaps?

 On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:

 def think we should support those specs in our great and fabled api
 audit…had not considered the load order issue

 not insurmountable and probably should be a feature/fix for the
 plugin
 loader load order …but also sort of scary… reminds me of script tags
 hell

 on that note: we need to make browserify thing first class. whats the
 hold
 up on that front?

 On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org
 wrote:

 Do we prefer to invent new cordova-specific apis, or prefer to
 match
 standard browser apis?  When there is no browser spec to match then
 design
 comes down to aesthetics and personal preference (as you say).  But
 often
 there is an existing browser spec, and then it comes down to match
 or
 fork.  I'm in the camp of preferring to match, and was under the
 assumption
 others here were too.

 Given the upcoming specs mentioned earlier (sockets, file,
 filesystem,
 permissions, service worker, fetch), seems that fighting the
 adoption
 of
 promises in core apis implies opposing the adoption of modern web
 specs.
 e.g. I'm assuming Andrew was referring to
 http://www.w3.org/TR/battery-status/, since matching that spec
 *would*
 require promises.


 Now, as I understand, you are not saying you are opposed to
 adoption
 of
 promises in Cordova, but that you are simply against the inclusion
 of a
 polyfill directly inside cordova-js.  I think that a
 promises-polyfill
 plugin alternative has some technical downsides [1], but they seem
 not
 so
 insurmountable that we shouldn't just get passed this debate and do
 that.

 In my opinion, we should prefer to create a common plugin (at least
 until
 browserify), since I really hope we don't tell devs to just include
 their
 own polyfill with each plugin.

 [1]:
 - Can't rely on a polyfill plugin for cordova-js itself.  There
 are a
 few
 places where that may have been useful.
 - We don't currently load plugins in an order that respects plugin
 dependencies, so every plugin relying on promises-polyfill will
 have
 to
 require() it at runtime before using  and forgetting to do so
 may-or-may-not lead to an error.  Maybe we just fix this in our
 plugin
 loader.
 - It seems odd that window.Promise will exist depending on which
 plugins
 you have installed.  While this technically isn't different than
 with
 any
 plugin modifying global symbols, it seems odd-er when applied to a
 dependant platform feature.

 -Michal

 On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com
 wrote:

 Why does battery-status 'require' promises?

 I agree that promises are here to stay, but I am unclear why it
 would
 be
 a
 good idea to go and change/rewrite/break our apis to use them?

 Most of the windows plugins use promises all over the place, the
 entire
 async windows js api is promise based, but this has zero impact
 on
 what
 our
 core-api looks like to 

Re: WebView Promise and W3C standards

[Andrew Grieve]

userland means that plugins won't be able to use them unless every plugin
also includes a copy of the polyfill within it.

Looking at our core APIs, seems maybe it's just battery-status that will
require it. Should we have battery-status include the polyfill within it? I
hope not. I'd hate to get to where several plugins in my app all bundle the
same polyfill.

If we move to having the entire cordova.js built using browserify where
every plugin gets to contribute to the JS that goes into it - yes I can see
this solving this use-case as well. But that also seems to me like a much
larger and much more controversial change.

Whether you are for or against promises - they are already here. They
exists natively on most latest mobile webviews, and every vendor has
committed to adding them. And they are being used in *most* new specs that
I've seen (sockets, filesystem, permissions, service worker, fetch)

Are there any concrete downsides to putting Promises polyfill right in
cordova-js?


On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser bows...@gmail.com wrote:

 +1 to userland. I see other approaches causing more problems.

 BTW: The only time I use promises is when the platform explicitly requires
 it, and right now that's just MozillaView.  While I think it looks awesome,
 I view Promises as a luxury right now and not a standard feature as of yet.

 I also really wish specs wouldn't rely on code that only exists on the very
 latest browsers. It just makes life harder on people who have to implement
 stuff.

Re: WebView Promise and W3C standards

[Ian Clelland]

On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve agri...@chromium.org
wrote:

 userland means that plugins won't be able to use them unless every plugin
 also includes a copy of the polyfill within it.

 Looking at our core APIs, seems maybe it's just battery-status that will
 require it. Should we have battery-status include the polyfill within it? I
 hope not. I'd hate to get to where several plugins in my app all bundle the
 same polyfill.


I believe that Mozilla's new File API, which I think we're planning to
implement, and which should be as core as File is now, is also heavily
promises-based.



 If we move to having the entire cordova.js built using browserify where
 every plugin gets to contribute to the JS that goes into it - yes I can see
 this solving this use-case as well. But that also seems to me like a much
 larger and much more controversial change.

 Whether you are for or against promises - they are already here. They
 exists natively on most latest mobile webviews, and every vendor has
 committed to adding them. And they are being used in *most* new specs that
 I've seen (sockets, filesystem, permissions, service worker, fetch)

 Are there any concrete downsides to putting Promises polyfill right in
 cordova-js?


As long as the promise doesn't clobber the native implementation, if it
exists, and we can remove it completely from platforms when they don't need
it anymore, it seems to me like a small price for having this available to
all platforms. (Other opinions vary, I'm sure, though)




 On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser bows...@gmail.com wrote:

  +1 to userland. I see other approaches causing more problems.
 
  BTW: The only time I use promises is when the platform explicitly
 requires
  it, and right now that's just MozillaView.  While I think it looks
 awesome,
  I view Promises as a luxury right now and not a standard feature as of
 yet.
 
  I also really wish specs wouldn't rely on code that only exists on the
 very
  latest browsers. It just makes life harder on people who have to
 implement
  stuff.
 

Re: WebView Promise and W3C standards

[Andrew Grieve]

One specific spot in core I'd like to use it is to address this TODO in
Android's exec bridge:

https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263

The actual need is for a setImmediate polyfill, but Promise does the same
thing (with an extra object creation).

On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland iclell...@chromium.org
wrote:

 On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve agri...@chromium.org
 wrote:

  userland means that plugins won't be able to use them unless every plugin
  also includes a copy of the polyfill within it.
 
  Looking at our core APIs, seems maybe it's just battery-status that will
  require it. Should we have battery-status include the polyfill within
 it? I
  hope not. I'd hate to get to where several plugins in my app all bundle
 the
  same polyfill.
 

 I believe that Mozilla's new File API, which I think we're planning to
 implement, and which should be as core as File is now, is also heavily
 promises-based.


 
  If we move to having the entire cordova.js built using browserify where
  every plugin gets to contribute to the JS that goes into it - yes I can
 see
  this solving this use-case as well. But that also seems to me like a much
  larger and much more controversial change.
 
  Whether you are for or against promises - they are already here. They
  exists natively on most latest mobile webviews, and every vendor has
  committed to adding them. And they are being used in *most* new specs
 that
  I've seen (sockets, filesystem, permissions, service worker, fetch)
 
  Are there any concrete downsides to putting Promises polyfill right in
  cordova-js?
 

 As long as the promise doesn't clobber the native implementation, if it
 exists, and we can remove it completely from platforms when they don't need
 it anymore, it seems to me like a small price for having this available to
 all platforms. (Other opinions vary, I'm sure, though)


 
 
  On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser bows...@gmail.com wrote:
 
   +1 to userland. I see other approaches causing more problems.
  
   BTW: The only time I use promises is when the platform explicitly
  requires
   it, and right now that's just MozillaView.  While I think it looks
  awesome,
   I view Promises as a luxury right now and not a standard feature as of
  yet.
  
   I also really wish specs wouldn't rely on code that only exists on the
  very
   latest browsers. It just makes life harder on people who have to
  implement
   stuff.
  
 

Re: WebView Promise and W3C standards

[Brian LeRoux]

- no technical benefit (but aesthetics, sure)
- adds weight (payload and runtime)
- might interfere with userland polly

-1

On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve agri...@chromium.org wrote:

 One specific spot in core I'd like to use it is to address this TODO in
 Android's exec bridge:

 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263

 The actual need is for a setImmediate polyfill, but Promise does the same
 thing (with an extra object creation).

 On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland iclell...@chromium.org
 wrote:

  On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve agri...@chromium.org
  wrote:
 
   userland means that plugins won't be able to use them unless every
 plugin
   also includes a copy of the polyfill within it.
  
   Looking at our core APIs, seems maybe it's just battery-status that
 will
   require it. Should we have battery-status include the polyfill within
  it? I
   hope not. I'd hate to get to where several plugins in my app all bundle
  the
   same polyfill.
  
 
  I believe that Mozilla's new File API, which I think we're planning to
  implement, and which should be as core as File is now, is also heavily
  promises-based.
 
 
  
   If we move to having the entire cordova.js built using browserify where
   every plugin gets to contribute to the JS that goes into it - yes I can
  see
   this solving this use-case as well. But that also seems to me like a
 much
   larger and much more controversial change.
  
   Whether you are for or against promises - they are already here. They
   exists natively on most latest mobile webviews, and every vendor has
   committed to adding them. And they are being used in *most* new specs
  that
   I've seen (sockets, filesystem, permissions, service worker, fetch)
  
   Are there any concrete downsides to putting Promises polyfill right in
   cordova-js?
  
 
  As long as the promise doesn't clobber the native implementation, if it
  exists, and we can remove it completely from platforms when they don't
 need
  it anymore, it seems to me like a small price for having this available
 to
  all platforms. (Other opinions vary, I'm sure, though)
 
 
  
  
   On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser bows...@gmail.com wrote:
  
+1 to userland. I see other approaches causing more problems.
   
BTW: The only time I use promises is when the platform explicitly
   requires
it, and right now that's just MozillaView.  While I think it looks
   awesome,
I view Promises as a luxury right now and not a standard feature as
 of
   yet.
   
I also really wish specs wouldn't rely on code that only exists on
 the
   very
latest browsers. It just makes life harder on people who have to
   implement
stuff.
   
  
 

Re: WebView Promise and W3C standards

[Jesse]

Why does battery-status 'require' promises?

I agree that promises are here to stay, but I am unclear why it would be a
good idea to go and change/rewrite/break our apis to use them?

Most of the windows plugins use promises all over the place, the entire
async windows js api is promise based, but this has zero impact on what our
core-api looks like to a user. The same should apply to any plugin that
wants to depend on promises, just depend on a promise plugin, which may or
may not add polyfil code to the dom.





@purplecabbage
risingj.com

On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux b...@brian.io wrote:

 - no technical benefit (but aesthetics, sure)
 - adds weight (payload and runtime)
 - might interfere with userland polly

 -1

 On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve agri...@chromium.org
 wrote:

  One specific spot in core I'd like to use it is to address this TODO in
  Android's exec bridge:
 
 
 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263
 
  The actual need is for a setImmediate polyfill, but Promise does the same
  thing (with an extra object creation).
 
  On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland iclell...@chromium.org
  wrote:
 
   On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve agri...@chromium.org
   wrote:
  
userland means that plugins won't be able to use them unless every
  plugin
also includes a copy of the polyfill within it.
   
Looking at our core APIs, seems maybe it's just battery-status that
  will
require it. Should we have battery-status include the polyfill within
   it? I
hope not. I'd hate to get to where several plugins in my app all
 bundle
   the
same polyfill.
   
  
   I believe that Mozilla's new File API, which I think we're planning to
   implement, and which should be as core as File is now, is also heavily
   promises-based.
  
  
   
If we move to having the entire cordova.js built using browserify
 where
every plugin gets to contribute to the JS that goes into it - yes I
 can
   see
this solving this use-case as well. But that also seems to me like a
  much
larger and much more controversial change.
   
Whether you are for or against promises - they are already here. They
exists natively on most latest mobile webviews, and every vendor has
committed to adding them. And they are being used in *most* new specs
   that
I've seen (sockets, filesystem, permissions, service worker, fetch)
   
Are there any concrete downsides to putting Promises polyfill right
 in
cordova-js?
   
  
   As long as the promise doesn't clobber the native implementation, if it
   exists, and we can remove it completely from platforms when they don't
  need
   it anymore, it seems to me like a small price for having this available
  to
   all platforms. (Other opinions vary, I'm sure, though)
  
  
   
   
On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser bows...@gmail.com
 wrote:
   
 +1 to userland. I see other approaches causing more problems.

 BTW: The only time I use promises is when the platform explicitly
requires
 it, and right now that's just MozillaView.  While I think it looks
awesome,
 I view Promises as a luxury right now and not a standard feature as
  of
yet.

 I also really wish specs wouldn't rely on code that only exists on
  the
very
 latest browsers. It just makes life harder on people who have to
implement
 stuff.

   
  
 

Re: WebView Promise and W3C standards

[Michal Mocny]

Do we prefer to invent new cordova-specific apis, or prefer to match
standard browser apis?  When there is no browser spec to match then design
comes down to aesthetics and personal preference (as you say).  But often
there is an existing browser spec, and then it comes down to match or
fork.  I'm in the camp of preferring to match, and was under the assumption
others here were too.

Given the upcoming specs mentioned earlier (sockets, file, filesystem,
permissions, service worker, fetch), seems that fighting the adoption of
promises in core apis implies opposing the adoption of modern web specs.
 e.g. I'm assuming Andrew was referring to
http://www.w3.org/TR/battery-status/, since matching that spec *would*
require promises.


Now, as I understand, you are not saying you are opposed to adoption of
promises in Cordova, but that you are simply against the inclusion of a
polyfill directly inside cordova-js.  I think that a promises-polyfill
plugin alternative has some technical downsides [1], but they seem not so
insurmountable that we shouldn't just get passed this debate and do that.

In my opinion, we should prefer to create a common plugin (at least until
browserify), since I really hope we don't tell devs to just include their
own polyfill with each plugin.

[1]:
- Can't rely on a polyfill plugin for cordova-js itself.  There are a few
places where that may have been useful.
- We don't currently load plugins in an order that respects plugin
dependencies, so every plugin relying on promises-polyfill will have to
require() it at runtime before using  and forgetting to do so
may-or-may-not lead to an error.  Maybe we just fix this in our plugin
loader.
- It seems odd that window.Promise will exist depending on which plugins
you have installed.  While this technically isn't different than with any
plugin modifying global symbols, it seems odd-er when applied to a
dependant platform feature.

-Michal

On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com wrote:

 Why does battery-status 'require' promises?

 I agree that promises are here to stay, but I am unclear why it would be a
 good idea to go and change/rewrite/break our apis to use them?

 Most of the windows plugins use promises all over the place, the entire
 async windows js api is promise based, but this has zero impact on what our
 core-api looks like to a user. The same should apply to any plugin that
 wants to depend on promises, just depend on a promise plugin, which may or
 may not add polyfil code to the dom.





 @purplecabbage
 risingj.com

 On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux b...@brian.io wrote:

  - no technical benefit (but aesthetics, sure)
  - adds weight (payload and runtime)
  - might interfere with userland polly
 
  -1
 
  On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve agri...@chromium.org
  wrote:
 
   One specific spot in core I'd like to use it is to address this TODO in
   Android's exec bridge:
  
  
 
 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263
  
   The actual need is for a setImmediate polyfill, but Promise does the
 same
   thing (with an extra object creation).
  
   On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland iclell...@chromium.org
 
   wrote:
  
On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve 
 agri...@chromium.org
wrote:
   
 userland means that plugins won't be able to use them unless every
   plugin
 also includes a copy of the polyfill within it.

 Looking at our core APIs, seems maybe it's just battery-status that
   will
 require it. Should we have battery-status include the polyfill
 within
it? I
 hope not. I'd hate to get to where several plugins in my app all
  bundle
the
 same polyfill.

   
I believe that Mozilla's new File API, which I think we're planning
 to
implement, and which should be as core as File is now, is also
 heavily
promises-based.
   
   

 If we move to having the entire cordova.js built using browserify
  where
 every plugin gets to contribute to the JS that goes into it - yes I
  can
see
 this solving this use-case as well. But that also seems to me like
 a
   much
 larger and much more controversial change.

 Whether you are for or against promises - they are already here.
 They
 exists natively on most latest mobile webviews, and every vendor
 has
 committed to adding them. And they are being used in *most* new
 specs
that
 I've seen (sockets, filesystem, permissions, service worker, fetch)

 Are there any concrete downsides to putting Promises polyfill right
  in
 cordova-js?

   
As long as the promise doesn't clobber the native implementation, if
 it
exists, and we can remove it completely from platforms when they
 don't
   need
it anymore, it seems to me like a small price for having this
 available
   to
all platforms. (Other opinions vary, I'm sure, though)
   
   


 On Fri, 

Re: WebView Promise and W3C standards

[Brian LeRoux]

def think we should support those specs in our great and fabled api
audit…had not considered the load order issue

not insurmountable and probably should be a feature/fix for the plugin
loader load order …but also sort of scary… reminds me of script tags hell

on that note: we need to make browserify thing first class. whats the hold
up on that front?

On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org wrote:

 Do we prefer to invent new cordova-specific apis, or prefer to match
 standard browser apis?  When there is no browser spec to match then design
 comes down to aesthetics and personal preference (as you say).  But often
 there is an existing browser spec, and then it comes down to match or
 fork.  I'm in the camp of preferring to match, and was under the assumption
 others here were too.

 Given the upcoming specs mentioned earlier (sockets, file, filesystem,
 permissions, service worker, fetch), seems that fighting the adoption of
 promises in core apis implies opposing the adoption of modern web specs.
  e.g. I'm assuming Andrew was referring to
 http://www.w3.org/TR/battery-status/, since matching that spec *would*
 require promises.


 Now, as I understand, you are not saying you are opposed to adoption of
 promises in Cordova, but that you are simply against the inclusion of a
 polyfill directly inside cordova-js.  I think that a promises-polyfill
 plugin alternative has some technical downsides [1], but they seem not so
 insurmountable that we shouldn't just get passed this debate and do that.

 In my opinion, we should prefer to create a common plugin (at least until
 browserify), since I really hope we don't tell devs to just include their
 own polyfill with each plugin.

 [1]:
 - Can't rely on a polyfill plugin for cordova-js itself.  There are a few
 places where that may have been useful.
 - We don't currently load plugins in an order that respects plugin
 dependencies, so every plugin relying on promises-polyfill will have to
 require() it at runtime before using  and forgetting to do so
 may-or-may-not lead to an error.  Maybe we just fix this in our plugin
 loader.
 - It seems odd that window.Promise will exist depending on which plugins
 you have installed.  While this technically isn't different than with any
 plugin modifying global symbols, it seems odd-er when applied to a
 dependant platform feature.

 -Michal

 On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com wrote:

  Why does battery-status 'require' promises?
 
  I agree that promises are here to stay, but I am unclear why it would be
 a
  good idea to go and change/rewrite/break our apis to use them?
 
  Most of the windows plugins use promises all over the place, the entire
  async windows js api is promise based, but this has zero impact on what
 our
  core-api looks like to a user. The same should apply to any plugin that
  wants to depend on promises, just depend on a promise plugin, which may
 or
  may not add polyfil code to the dom.
 
 
 
 
 
  @purplecabbage
  risingj.com
 
  On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux b...@brian.io wrote:
 
   - no technical benefit (but aesthetics, sure)
   - adds weight (payload and runtime)
   - might interfere with userland polly
  
   -1
  
   On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve agri...@chromium.org
   wrote:
  
One specific spot in core I'd like to use it is to address this TODO
 in
Android's exec bridge:
   
   
  
 
 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263
   
The actual need is for a setImmediate polyfill, but Promise does the
  same
thing (with an extra object creation).
   
On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland 
 iclell...@chromium.org
  
wrote:
   
 On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve 
  agri...@chromium.org
 wrote:

  userland means that plugins won't be able to use them unless
 every
plugin
  also includes a copy of the polyfill within it.
 
  Looking at our core APIs, seems maybe it's just battery-status
 that
will
  require it. Should we have battery-status include the polyfill
  within
 it? I
  hope not. I'd hate to get to where several plugins in my app all
   bundle
 the
  same polyfill.
 

 I believe that Mozilla's new File API, which I think we're planning
  to
 implement, and which should be as core as File is now, is also
  heavily
 promises-based.


 
  If we move to having the entire cordova.js built using browserify
   where
  every plugin gets to contribute to the JS that goes into it -
 yes I
   can
 see
  this solving this use-case as well. But that also seems to me
 like
  a
much
  larger and much more controversial change.
 
  Whether you are for or against promises - they are already here.
  They
  exists natively on most latest mobile webviews, and every vendor
  has
  committed to adding them. And they 

Re: WebView Promise and W3C standards

[Michal Mocny]

We haven't worked on it, also curious.  Anis, perhaps?

On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:

 def think we should support those specs in our great and fabled api
 audit…had not considered the load order issue

 not insurmountable and probably should be a feature/fix for the plugin
 loader load order …but also sort of scary… reminds me of script tags hell

 on that note: we need to make browserify thing first class. whats the hold
 up on that front?

 On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org
 wrote:

  Do we prefer to invent new cordova-specific apis, or prefer to match
  standard browser apis?  When there is no browser spec to match then
 design
  comes down to aesthetics and personal preference (as you say).  But often
  there is an existing browser spec, and then it comes down to match or
  fork.  I'm in the camp of preferring to match, and was under the
 assumption
  others here were too.
 
  Given the upcoming specs mentioned earlier (sockets, file, filesystem,
  permissions, service worker, fetch), seems that fighting the adoption of
  promises in core apis implies opposing the adoption of modern web specs.
   e.g. I'm assuming Andrew was referring to
  http://www.w3.org/TR/battery-status/, since matching that spec *would*
  require promises.
 
 
  Now, as I understand, you are not saying you are opposed to adoption of
  promises in Cordova, but that you are simply against the inclusion of a
  polyfill directly inside cordova-js.  I think that a promises-polyfill
  plugin alternative has some technical downsides [1], but they seem not so
  insurmountable that we shouldn't just get passed this debate and do that.
 
  In my opinion, we should prefer to create a common plugin (at least until
  browserify), since I really hope we don't tell devs to just include their
  own polyfill with each plugin.
 
  [1]:
  - Can't rely on a polyfill plugin for cordova-js itself.  There are a few
  places where that may have been useful.
  - We don't currently load plugins in an order that respects plugin
  dependencies, so every plugin relying on promises-polyfill will have to
  require() it at runtime before using  and forgetting to do so
  may-or-may-not lead to an error.  Maybe we just fix this in our plugin
  loader.
  - It seems odd that window.Promise will exist depending on which plugins
  you have installed.  While this technically isn't different than with any
  plugin modifying global symbols, it seems odd-er when applied to a
  dependant platform feature.
 
  -Michal
 
  On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com wrote:
 
   Why does battery-status 'require' promises?
  
   I agree that promises are here to stay, but I am unclear why it would
 be
  a
   good idea to go and change/rewrite/break our apis to use them?
  
   Most of the windows plugins use promises all over the place, the entire
   async windows js api is promise based, but this has zero impact on what
  our
   core-api looks like to a user. The same should apply to any plugin that
   wants to depend on promises, just depend on a promise plugin, which may
  or
   may not add polyfil code to the dom.
  
  
  
  
  
   @purplecabbage
   risingj.com
  
   On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux b...@brian.io wrote:
  
- no technical benefit (but aesthetics, sure)
- adds weight (payload and runtime)
- might interfere with userland polly
   
-1
   
On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve agri...@chromium.org
 
wrote:
   
 One specific spot in core I'd like to use it is to address this
 TODO
  in
 Android's exec bridge:


   
  
 
 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263

 The actual need is for a setImmediate polyfill, but Promise does
 the
   same
 thing (with an extra object creation).

 On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland 
  iclell...@chromium.org
   
 wrote:

  On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve 
   agri...@chromium.org
  wrote:
 
   userland means that plugins won't be able to use them unless
  every
 plugin
   also includes a copy of the polyfill within it.
  
   Looking at our core APIs, seems maybe it's just battery-status
  that
 will
   require it. Should we have battery-status include the polyfill
   within
  it? I
   hope not. I'd hate to get to where several plugins in my app
 all
bundle
  the
   same polyfill.
  
 
  I believe that Mozilla's new File API, which I think we're
 planning
   to
  implement, and which should be as core as File is now, is also
   heavily
  promises-based.
 
 
  
   If we move to having the entire cordova.js built using
 browserify
where
   every plugin gets to contribute to the JS that goes into it -
  yes I
can
  see
   this solving this use-case as well. But that also seems to me

Re: WebView Promise and W3C standards

[Jesse]

So far I have approached browser polyfils with an outside-in approach.
For example, there are issues in the C# + WP8 browser implementation of
XMLHttpRequest  which prevent xhr calls to the local filesystem.  This
could have been resolved by adding platform specific code to cordova-js,
but my solution was to patch this from the native side, and supplement the
cordovaview itself.

Would it make more sense to do a similar thing with Promises? ie. Inject
them from the native side where they do not exist.

Also, about the plugin loader. We force users to wait for the deviceready
event before calling any of our apis, is it reasonable to make them wait
for deviceready before using Promises?

I slapped together a quick plugin based on the es6-promise, this works on
wp8 which does not have intrinsic promises, but only after device ready.

https://github.com/purplecabbage/promiscuous



@purplecabbage
risingj.com

On Wed, Dec 10, 2014 at 1:22 PM, Michal Mocny mmo...@chromium.org wrote:

 We haven't worked on it, also curious.  Anis, perhaps?

 On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:

  def think we should support those specs in our great and fabled api
  audit…had not considered the load order issue
 
  not insurmountable and probably should be a feature/fix for the plugin
  loader load order …but also sort of scary… reminds me of script tags hell
 
  on that note: we need to make browserify thing first class. whats the
 hold
  up on that front?
 
  On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
   Do we prefer to invent new cordova-specific apis, or prefer to match
   standard browser apis?  When there is no browser spec to match then
  design
   comes down to aesthetics and personal preference (as you say).  But
 often
   there is an existing browser spec, and then it comes down to match or
   fork.  I'm in the camp of preferring to match, and was under the
  assumption
   others here were too.
  
   Given the upcoming specs mentioned earlier (sockets, file, filesystem,
   permissions, service worker, fetch), seems that fighting the adoption
 of
   promises in core apis implies opposing the adoption of modern web
 specs.
e.g. I'm assuming Andrew was referring to
   http://www.w3.org/TR/battery-status/, since matching that spec *would*
   require promises.
  
  
   Now, as I understand, you are not saying you are opposed to adoption of
   promises in Cordova, but that you are simply against the inclusion of a
   polyfill directly inside cordova-js.  I think that a promises-polyfill
   plugin alternative has some technical downsides [1], but they seem not
 so
   insurmountable that we shouldn't just get passed this debate and do
 that.
  
   In my opinion, we should prefer to create a common plugin (at least
 until
   browserify), since I really hope we don't tell devs to just include
 their
   own polyfill with each plugin.
  
   [1]:
   - Can't rely on a polyfill plugin for cordova-js itself.  There are a
 few
   places where that may have been useful.
   - We don't currently load plugins in an order that respects plugin
   dependencies, so every plugin relying on promises-polyfill will have to
   require() it at runtime before using  and forgetting to do so
   may-or-may-not lead to an error.  Maybe we just fix this in our plugin
   loader.
   - It seems odd that window.Promise will exist depending on which
 plugins
   you have installed.  While this technically isn't different than with
 any
   plugin modifying global symbols, it seems odd-er when applied to a
   dependant platform feature.
  
   -Michal
  
   On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com
 wrote:
  
Why does battery-status 'require' promises?
   
I agree that promises are here to stay, but I am unclear why it would
  be
   a
good idea to go and change/rewrite/break our apis to use them?
   
Most of the windows plugins use promises all over the place, the
 entire
async windows js api is promise based, but this has zero impact on
 what
   our
core-api looks like to a user. The same should apply to any plugin
 that
wants to depend on promises, just depend on a promise plugin, which
 may
   or
may not add polyfil code to the dom.
   
   
   
   
   
@purplecabbage
risingj.com
   
On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux b...@brian.io wrote:
   
 - no technical benefit (but aesthetics, sure)
 - adds weight (payload and runtime)
 - might interfere with userland polly

 -1

 On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve 
 agri...@chromium.org
  
 wrote:

  One specific spot in core I'd like to use it is to address this
  TODO
   in
  Android's exec bridge:
 
 

   
  
 
 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263
 
  The actual need is for a setImmediate polyfill, but Promise does
  the
same
  thing (with an extra object 

Re: WebView Promise and W3C standards

[Andrew Grieve]

There's something implemented behind a --browserify flag, but not sure what
it does.

Totally in favour of having CLI / plugman concatenate plugin JS with
cordova.js, but not convinced that browserify is the right tool for this,
as it seems quite heavy-weight for just concatenating things. If someone is
going to resume work on it, would love to hear a summary of what problems
it's solving (if more than concatenation), and why something more
light-weight wouldn't be better.

On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny mmo...@chromium.org wrote:

 We haven't worked on it, also curious.  Anis, perhaps?

 On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:

  def think we should support those specs in our great and fabled api
  audit…had not considered the load order issue
 
  not insurmountable and probably should be a feature/fix for the plugin
  loader load order …but also sort of scary… reminds me of script tags hell
 
  on that note: we need to make browserify thing first class. whats the
 hold
  up on that front?
 
  On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org
  wrote:
 
   Do we prefer to invent new cordova-specific apis, or prefer to match
   standard browser apis?  When there is no browser spec to match then
  design
   comes down to aesthetics and personal preference (as you say).  But
 often
   there is an existing browser spec, and then it comes down to match or
   fork.  I'm in the camp of preferring to match, and was under the
  assumption
   others here were too.
  
   Given the upcoming specs mentioned earlier (sockets, file, filesystem,
   permissions, service worker, fetch), seems that fighting the adoption
 of
   promises in core apis implies opposing the adoption of modern web
 specs.
e.g. I'm assuming Andrew was referring to
   http://www.w3.org/TR/battery-status/, since matching that spec *would*
   require promises.
  
  
   Now, as I understand, you are not saying you are opposed to adoption of
   promises in Cordova, but that you are simply against the inclusion of a
   polyfill directly inside cordova-js.  I think that a promises-polyfill
   plugin alternative has some technical downsides [1], but they seem not
 so
   insurmountable that we shouldn't just get passed this debate and do
 that.
  
   In my opinion, we should prefer to create a common plugin (at least
 until
   browserify), since I really hope we don't tell devs to just include
 their
   own polyfill with each plugin.
  
   [1]:
   - Can't rely on a polyfill plugin for cordova-js itself.  There are a
 few
   places where that may have been useful.
   - We don't currently load plugins in an order that respects plugin
   dependencies, so every plugin relying on promises-polyfill will have to
   require() it at runtime before using  and forgetting to do so
   may-or-may-not lead to an error.  Maybe we just fix this in our plugin
   loader.
   - It seems odd that window.Promise will exist depending on which
 plugins
   you have installed.  While this technically isn't different than with
 any
   plugin modifying global symbols, it seems odd-er when applied to a
   dependant platform feature.
  
   -Michal
  
   On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com
 wrote:
  
Why does battery-status 'require' promises?
   
I agree that promises are here to stay, but I am unclear why it would
  be
   a
good idea to go and change/rewrite/break our apis to use them?
   
Most of the windows plugins use promises all over the place, the
 entire
async windows js api is promise based, but this has zero impact on
 what
   our
core-api looks like to a user. The same should apply to any plugin
 that
wants to depend on promises, just depend on a promise plugin, which
 may
   or
may not add polyfil code to the dom.
   
   
   
   
   
@purplecabbage
risingj.com
   
On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux b...@brian.io wrote:
   
 - no technical benefit (but aesthetics, sure)
 - adds weight (payload and runtime)
 - might interfere with userland polly

 -1

 On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve 
 agri...@chromium.org
  
 wrote:

  One specific spot in core I'd like to use it is to address this
  TODO
   in
  Android's exec bridge:
 
 

   
  
 
 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263
 
  The actual need is for a setImmediate polyfill, but Promise does
  the
same
  thing (with an extra object creation).
 
  On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland 
   iclell...@chromium.org

  wrote:
 
   On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve 
agri...@chromium.org
   wrote:
  
userland means that plugins won't be able to use them unless
   every
  plugin
also includes a copy of the polyfill within it.
   
Looking at our core APIs, seems maybe it's just
 

Re: WebView Promise and W3C standards

[Brian LeRoux]

we should move browserify to main and drop that insane concat code

its not heavyweight at all. it creates a hash in iife with deps mapped
in…as to why dep mgmt is better than concatenating…I don't think we need to
waste our time talking about that!

On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve agri...@chromium.org wrote:

 There's something implemented behind a --browserify flag, but not sure what
 it does.

 Totally in favour of having CLI / plugman concatenate plugin JS with
 cordova.js, but not convinced that browserify is the right tool for this,
 as it seems quite heavy-weight for just concatenating things. If someone is
 going to resume work on it, would love to hear a summary of what problems
 it's solving (if more than concatenation), and why something more
 light-weight wouldn't be better.

 On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny mmo...@chromium.org wrote:

  We haven't worked on it, also curious.  Anis, perhaps?
 
  On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:
 
   def think we should support those specs in our great and fabled api
   audit…had not considered the load order issue
  
   not insurmountable and probably should be a feature/fix for the plugin
   loader load order …but also sort of scary… reminds me of script tags
 hell
  
   on that note: we need to make browserify thing first class. whats the
  hold
   up on that front?
  
   On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org
   wrote:
  
Do we prefer to invent new cordova-specific apis, or prefer to match
standard browser apis?  When there is no browser spec to match then
   design
comes down to aesthetics and personal preference (as you say).  But
  often
there is an existing browser spec, and then it comes down to match or
fork.  I'm in the camp of preferring to match, and was under the
   assumption
others here were too.
   
Given the upcoming specs mentioned earlier (sockets, file,
 filesystem,
permissions, service worker, fetch), seems that fighting the adoption
  of
promises in core apis implies opposing the adoption of modern web
  specs.
 e.g. I'm assuming Andrew was referring to
http://www.w3.org/TR/battery-status/, since matching that spec
 *would*
require promises.
   
   
Now, as I understand, you are not saying you are opposed to adoption
 of
promises in Cordova, but that you are simply against the inclusion
 of a
polyfill directly inside cordova-js.  I think that a
 promises-polyfill
plugin alternative has some technical downsides [1], but they seem
 not
  so
insurmountable that we shouldn't just get passed this debate and do
  that.
   
In my opinion, we should prefer to create a common plugin (at least
  until
browserify), since I really hope we don't tell devs to just include
  their
own polyfill with each plugin.
   
[1]:
- Can't rely on a polyfill plugin for cordova-js itself.  There are a
  few
places where that may have been useful.
- We don't currently load plugins in an order that respects plugin
dependencies, so every plugin relying on promises-polyfill will have
 to
require() it at runtime before using  and forgetting to do so
may-or-may-not lead to an error.  Maybe we just fix this in our
 plugin
loader.
- It seems odd that window.Promise will exist depending on which
  plugins
you have installed.  While this technically isn't different than with
  any
plugin modifying global symbols, it seems odd-er when applied to a
dependant platform feature.
   
-Michal
   
On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com
  wrote:
   
 Why does battery-status 'require' promises?

 I agree that promises are here to stay, but I am unclear why it
 would
   be
a
 good idea to go and change/rewrite/break our apis to use them?

 Most of the windows plugins use promises all over the place, the
  entire
 async windows js api is promise based, but this has zero impact on
  what
our
 core-api looks like to a user. The same should apply to any plugin
  that
 wants to depend on promises, just depend on a promise plugin, which
  may
or
 may not add polyfil code to the dom.





 @purplecabbage
 risingj.com

 On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux b...@brian.io wrote:

  - no technical benefit (but aesthetics, sure)
  - adds weight (payload and runtime)
  - might interfere with userland polly
 
  -1
 
  On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve 
  agri...@chromium.org
   
  wrote:
 
   One specific spot in core I'd like to use it is to address this
   TODO
in
   Android's exec bridge:
  
  
 

   
  
 
 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263
  
   The actual need is for a setImmediate polyfill, but Promise
 does
   the
 same
  

Re: WebView Promise and W3C standards

[Michal Mocny]

Jesse: yes, that could work.  By setting your polyfill to runs/ you'll be
sure it is available after pluginsready (and thus deviceready).  For
plugins that use Promises during bootstrap, which is unlikely to be common,
the explicit require() on the polyfill is still an option.

Regarding your Native injection suggestion: how early on in the boot
process can we do this?  i.e. do you modify the startPage to inject this
before loading cordova.js, or do you do it in response to an exec bridge
call, making the timing about equivalent to the js polyfill?

-Michal

On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:

 we should move browserify to main and drop that insane concat code

 its not heavyweight at all. it creates a hash in iife with deps mapped
 in…as to why dep mgmt is better than concatenating…I don't think we need to
 waste our time talking about that!

 On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve agri...@chromium.org
 wrote:

  There's something implemented behind a --browserify flag, but not sure
 what
  it does.
 
  Totally in favour of having CLI / plugman concatenate plugin JS with
  cordova.js, but not convinced that browserify is the right tool for this,
  as it seems quite heavy-weight for just concatenating things. If someone
 is
  going to resume work on it, would love to hear a summary of what problems
  it's solving (if more than concatenation), and why something more
  light-weight wouldn't be better.
 
  On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
   We haven't worked on it, also curious.  Anis, perhaps?
  
   On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:
  
def think we should support those specs in our great and fabled api
audit…had not considered the load order issue
   
not insurmountable and probably should be a feature/fix for the
 plugin
loader load order …but also sort of scary… reminds me of script tags
  hell
   
on that note: we need to make browserify thing first class. whats the
   hold
up on that front?
   
On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org
wrote:
   
 Do we prefer to invent new cordova-specific apis, or prefer to
 match
 standard browser apis?  When there is no browser spec to match then
design
 comes down to aesthetics and personal preference (as you say).  But
   often
 there is an existing browser spec, and then it comes down to match
 or
 fork.  I'm in the camp of preferring to match, and was under the
assumption
 others here were too.

 Given the upcoming specs mentioned earlier (sockets, file,
  filesystem,
 permissions, service worker, fetch), seems that fighting the
 adoption
   of
 promises in core apis implies opposing the adoption of modern web
   specs.
  e.g. I'm assuming Andrew was referring to
 http://www.w3.org/TR/battery-status/, since matching that spec
  *would*
 require promises.


 Now, as I understand, you are not saying you are opposed to
 adoption
  of
 promises in Cordova, but that you are simply against the inclusion
  of a
 polyfill directly inside cordova-js.  I think that a
  promises-polyfill
 plugin alternative has some technical downsides [1], but they seem
  not
   so
 insurmountable that we shouldn't just get passed this debate and do
   that.

 In my opinion, we should prefer to create a common plugin (at least
   until
 browserify), since I really hope we don't tell devs to just include
   their
 own polyfill with each plugin.

 [1]:
 - Can't rely on a polyfill plugin for cordova-js itself.  There
 are a
   few
 places where that may have been useful.
 - We don't currently load plugins in an order that respects plugin
 dependencies, so every plugin relying on promises-polyfill will
 have
  to
 require() it at runtime before using  and forgetting to do so
 may-or-may-not lead to an error.  Maybe we just fix this in our
  plugin
 loader.
 - It seems odd that window.Promise will exist depending on which
   plugins
 you have installed.  While this technically isn't different than
 with
   any
 plugin modifying global symbols, it seems odd-er when applied to a
 dependant platform feature.

 -Michal

 On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com
   wrote:

  Why does battery-status 'require' promises?
 
  I agree that promises are here to stay, but I am unclear why it
  would
be
 a
  good idea to go and change/rewrite/break our apis to use them?
 
  Most of the windows plugins use promises all over the place, the
   entire
  async windows js api is promise based, but this has zero impact
 on
   what
 our
  core-api looks like to a user. The same should apply to any
 plugin
   that
  wants to depend on promises, just depend on a promise plugin,
 which
   may
 or
 

Re: WebView Promise and W3C standards

[Max Woghiren]

I've created a topic branch called promise
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/promise
to cordova-js.  It has a commit that adds this ES6 promise polyfill
https://github.com/jakearchibald/es6-promise (minified) to cordova.js and
a simple test to ensure it's found.

That's literally all it is right now—please take a look, though.  Shall we
move forward on this?

On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins br...@bryanhiggins.net
wrote:

 BB10 does have a native secure element API. I may be able to dig up some
 code which bridges this to JavaScript.


 On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker ignisvul...@gmail.com
 wrote:

  I created https://issues.apache.org/jira/browse/CB-7310 to track this.
 
 
  2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:
 
   Good to know. Thanks.
Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:
  
   Axel Nennker wrote:
   I am interested to implement the secure element API.
   Mozilla is currently implementing it with our help for FFOS but I
 want
  it
   for Android too. Blackberry shouldn't be that difficult using JSR177.
  
   BlackBerry classic (which is built around Java) isn't supported by
  Cordova
   and hasn't been for a few releases.
   BlackBerry 10 is built around QNX.
  
   I'm not making a statement about implementability re BB10 (just that
  Java
   is irrelevant),
  
  
 
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
   l
  
   Is probably where someone would go to start...
  
  
 

Re: WebView Promise and W3C standards

[Jesse]

Nice, but please don't add this. 
Anyone who wants or needs this can do what you did, and if I start seeing 
promise code throughout Cordova.js I may run. 

We should be looking to get rid of Cordova.js entirely, not add more deps. 

Why not a promise plugin?

Fyi: promises invoke my fight or flight response, and I have only found them 
useful for blocking contribution. That said, they already exist in windows8.1 
as part of winjs. 


Sent from mobile

 On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org wrote:
 
 I've created a topic branch called promise
 https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/promise
 to cordova-js.  It has a commit that adds this ES6 promise polyfill
 https://github.com/jakearchibald/es6-promise (minified) to cordova.js and
 a simple test to ensure it's found.
 
 That's literally all it is right now—please take a look, though.  Shall we
 move forward on this?
 
 On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:
 
 BB10 does have a native secure element API. I may be able to dig up some
 code which bridges this to JavaScript.
 
 
 On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker ignisvul...@gmail.com
 wrote:
 
 I created https://issues.apache.org/jira/browse/CB-7310 to track this.
 
 
 2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:
 
 Good to know. Thanks.
 Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:
 
 Axel Nennker wrote:
 I am interested to implement the secure element API.
 Mozilla is currently implementing it with our help for FFOS but I
 want
 it
 for Android too. Blackberry shouldn't be that difficult using JSR177.
 
 BlackBerry classic (which is built around Java) isn't supported by
 Cordova
 and hasn't been for a few releases.
 BlackBerry 10 is built around QNX.
 
 I'm not making a statement about implementability re BB10 (just that
 Java
 is irrelevant),
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
 l
 
 Is probably where someone would go to start...
 

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: WebView Promise and W3C standards

[Max Woghiren]

I think it's nice to remove that obstacle from in front of plugin
developers who want to use promises.  If we're going to suggest that people
drop the polyfill in themselves, I don't see the harm in just having it
there, especially if we don't mandate its use.

Going forward, many/most APIs will use promises; it might get a little
unwieldy to have a whole bunch of plugins depend on a promise plugin.

The bottom line, for me, is that this doesn't force anyone to use promises;
it's just easy and there for those who want it.

On Fri, Dec 5, 2014 at 12:11 PM, Jesse purplecabb...@gmail.com wrote:

 Nice, but please don't add this.
 Anyone who wants or needs this can do what you did, and if I start seeing
 promise code throughout Cordova.js I may run.

 We should be looking to get rid of Cordova.js entirely, not add more deps.

 Why not a promise plugin?

 Fyi: promises invoke my fight or flight response, and I have only found
 them useful for blocking contribution. That said, they already exist in
 windows8.1 as part of winjs.


 Sent from mobile

  On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org wrote:
 
  I've created a topic branch called promise
  
 https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/promise
 
  to cordova-js.  It has a commit that adds this ES6 promise polyfill
  https://github.com/jakearchibald/es6-promise (minified) to cordova.js
 and
  a simple test to ensure it's found.
 
  That's literally all it is right now—please take a look, though.  Shall
 we
  move forward on this?
 
  On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins br...@bryanhiggins.net
  wrote:
 
  BB10 does have a native secure element API. I may be able to dig up some
  code which bridges this to JavaScript.
 
 
  On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker ignisvul...@gmail.com
  wrote:
 
  I created https://issues.apache.org/jira/browse/CB-7310 to track this.
 
 
  2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:
 
  Good to know. Thanks.
  Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:
 
  Axel Nennker wrote:
  I am interested to implement the secure element API.
  Mozilla is currently implementing it with our help for FFOS but I
  want
  it
  for Android too. Blackberry shouldn't be that difficult using
 JSR177.
 
  BlackBerry classic (which is built around Java) isn't supported by
  Cordova
  and hasn't been for a few releases.
  BlackBerry 10 is built around QNX.
 
  I'm not making a statement about implementability re BB10 (just that
  Java
  is irrelevant),
 
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
  l
 
  Is probably where someone would go to start...
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: WebView Promise and W3C standards

[Jesse]

We would be mandating its support, we have plenty of issues in Jira,
and this solves none of them.
... and minified code? Why? How can I evaluate it?

My mantra is and will remain Plugins are everything, and everything
is a plugin
What is the inconvenience in having a dependency on a promise plugin?
I don't see the downside, and I think it would be perfect for those
who want to use it.

Personally I think we should be pushing the browserify functionality
in cordova-js, and ripping stuff out, not adding it.


 On Dec 5, 2014, at 9:59 AM, Max Woghiren m...@chromium.org wrote:

 I think it's nice to remove that obstacle from in front of plugin
 developers who want to use promises.  If we're going to suggest that people
 drop the polyfill in themselves, I don't see the harm in just having it
 there, especially if we don't mandate its use.

 Going forward, many/most APIs will use promises; it might get a little
 unwieldy to have a whole bunch of plugins depend on a promise plugin.

 The bottom line, for me, is that this doesn't force anyone to use promises;
 it's just easy and there for those who want it.

 On Fri, Dec 5, 2014 at 12:11 PM, Jesse purplecabb...@gmail.com wrote:

 Nice, but please don't add this.
 Anyone who wants or needs this can do what you did, and if I start seeing
 promise code throughout Cordova.js I may run.

 We should be looking to get rid of Cordova.js entirely, not add more deps.

 Why not a promise plugin?

 Fyi: promises invoke my fight or flight response, and I have only found
 them useful for blocking contribution. That said, they already exist in
 windows8.1 as part of winjs.


 Sent from mobile

 On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org wrote:

 I've created a topic branch called promise
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/promise

 to cordova-js.  It has a commit that adds this ES6 promise polyfill
 https://github.com/jakearchibald/es6-promise (minified) to cordova.js
 and
 a simple test to ensure it's found.

 That's literally all it is right now—please take a look, though.  Shall
 we
 move forward on this?

 On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

 BB10 does have a native secure element API. I may be able to dig up some
 code which bridges this to JavaScript.


 On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker ignisvul...@gmail.com
 wrote:

 I created https://issues.apache.org/jira/browse/CB-7310 to track this.


 2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:

 Good to know. Thanks.
 Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:

 Axel Nennker wrote:
 I am interested to implement the secure element API.
 Mozilla is currently implementing it with our help for FFOS but I
 want
 it
 for Android too. Blackberry shouldn't be that difficult using
 JSR177.

 BlackBerry classic (which is built around Java) isn't supported by
 Cordova
 and hasn't been for a few releases.
 BlackBerry 10 is built around QNX.

 I'm not making a statement about implementability re BB10 (just that
 Java
 is irrelevant),
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
 l

 Is probably where someone would go to start...

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: WebView Promise and W3C standards

[Brian LeRoux]

Minified code is a flat out bad idea and needs to be reverted immediately.
Jesse is right about promises too. Given that native support is immediately
inbound it most certainly should be a plugin. Not core.

I'll reserve debate about it as a lang feature for the drama queens on
hacker news and twitter. ;)

On Fri, Dec 5, 2014 at 11:10 AM, Jesse purplecabb...@gmail.com wrote:

 We would be mandating its support, we have plenty of issues in Jira,
 and this solves none of them.
 ... and minified code? Why? How can I evaluate it?

 My mantra is and will remain Plugins are everything, and everything
 is a plugin
 What is the inconvenience in having a dependency on a promise plugin?
 I don't see the downside, and I think it would be perfect for those
 who want to use it.

 Personally I think we should be pushing the browserify functionality
 in cordova-js, and ripping stuff out, not adding it.


  On Dec 5, 2014, at 9:59 AM, Max Woghiren m...@chromium.org wrote:
 
  I think it's nice to remove that obstacle from in front of plugin
  developers who want to use promises.  If we're going to suggest that
 people
  drop the polyfill in themselves, I don't see the harm in just having it
  there, especially if we don't mandate its use.
 
  Going forward, many/most APIs will use promises; it might get a little
  unwieldy to have a whole bunch of plugins depend on a promise plugin.
 
  The bottom line, for me, is that this doesn't force anyone to use
 promises;
  it's just easy and there for those who want it.
 
  On Fri, Dec 5, 2014 at 12:11 PM, Jesse purplecabb...@gmail.com wrote:
 
  Nice, but please don't add this.
  Anyone who wants or needs this can do what you did, and if I start
 seeing
  promise code throughout Cordova.js I may run.
 
  We should be looking to get rid of Cordova.js entirely, not add more
 deps.
 
  Why not a promise plugin?
 
  Fyi: promises invoke my fight or flight response, and I have only found
  them useful for blocking contribution. That said, they already exist in
  windows8.1 as part of winjs.
 
 
  Sent from mobile
 
  On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org wrote:
 
  I've created a topic branch called promise
  
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/promise
 
  to cordova-js.  It has a commit that adds this ES6 promise polyfill
  https://github.com/jakearchibald/es6-promise (minified) to
 cordova.js
  and
  a simple test to ensure it's found.
 
  That's literally all it is right now—please take a look, though.  Shall
  we
  move forward on this?
 
  On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins br...@bryanhiggins.net
 
  wrote:
 
  BB10 does have a native secure element API. I may be able to dig up
 some
  code which bridges this to JavaScript.
 
 
  On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker ignisvul...@gmail.com
  wrote:
 
  I created https://issues.apache.org/jira/browse/CB-7310 to track
 this.
 
 
  2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:
 
  Good to know. Thanks.
  Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:
 
  Axel Nennker wrote:
  I am interested to implement the secure element API.
  Mozilla is currently implementing it with our help for FFOS but I
  want
  it
  for Android too. Blackberry shouldn't be that difficult using
  JSR177.
 
  BlackBerry classic (which is built around Java) isn't supported by
  Cordova
  and hasn't been for a few releases.
  BlackBerry 10 is built around QNX.
 
  I'm not making a statement about implementability re BB10 (just
 that
  Java
  is irrelevant),
 
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
  l
 
  Is probably where someone would go to start...
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: WebView Promise and W3C standards

[Max Woghiren]

I can easily change to expanded (non-minified) code; I went with smaller
size, expecting that people wouldn't be wanting to inspect the promise
polyfill code.  No big deal.

Earlier in this very thread, people (Jesse included) asserted that it
should be in core, and Andrew outlined rationale.  I was trying to make
progress on a task that seemed like a go-ahead and was then left hanging.
If enough people believe it should be a plugin, then we can certainly go
that way.  Looking forward to more input.

On Fri, Dec 5, 2014 at 2:10 PM, Jesse purplecabb...@gmail.com wrote:

 We would be mandating its support, we have plenty of issues in Jira,
 and this solves none of them.
 ... and minified code? Why? How can I evaluate it?

 My mantra is and will remain Plugins are everything, and everything
 is a plugin
 What is the inconvenience in having a dependency on a promise plugin?
 I don't see the downside, and I think it would be perfect for those
 who want to use it.

 Personally I think we should be pushing the browserify functionality
 in cordova-js, and ripping stuff out, not adding it.


  On Dec 5, 2014, at 9:59 AM, Max Woghiren m...@chromium.org wrote:
 
  I think it's nice to remove that obstacle from in front of plugin
  developers who want to use promises.  If we're going to suggest that
 people
  drop the polyfill in themselves, I don't see the harm in just having it
  there, especially if we don't mandate its use.
 
  Going forward, many/most APIs will use promises; it might get a little
  unwieldy to have a whole bunch of plugins depend on a promise plugin.
 
  The bottom line, for me, is that this doesn't force anyone to use
 promises;
  it's just easy and there for those who want it.
 
  On Fri, Dec 5, 2014 at 12:11 PM, Jesse purplecabb...@gmail.com wrote:
 
  Nice, but please don't add this.
  Anyone who wants or needs this can do what you did, and if I start
 seeing
  promise code throughout Cordova.js I may run.
 
  We should be looking to get rid of Cordova.js entirely, not add more
 deps.
 
  Why not a promise plugin?
 
  Fyi: promises invoke my fight or flight response, and I have only found
  them useful for blocking contribution. That said, they already exist in
  windows8.1 as part of winjs.
 
 
  Sent from mobile
 
  On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org wrote:
 
  I've created a topic branch called promise
  
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/promise
 
  to cordova-js.  It has a commit that adds this ES6 promise polyfill
  https://github.com/jakearchibald/es6-promise (minified) to
 cordova.js
  and
  a simple test to ensure it's found.
 
  That's literally all it is right now—please take a look, though.  Shall
  we
  move forward on this?
 
  On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins br...@bryanhiggins.net
 
  wrote:
 
  BB10 does have a native secure element API. I may be able to dig up
 some
  code which bridges this to JavaScript.
 
 
  On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker ignisvul...@gmail.com
  wrote:
 
  I created https://issues.apache.org/jira/browse/CB-7310 to track
 this.
 
 
  2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:
 
  Good to know. Thanks.
  Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:
 
  Axel Nennker wrote:
  I am interested to implement the secure element API.
  Mozilla is currently implementing it with our help for FFOS but I
  want
  it
  for Android too. Blackberry shouldn't be that difficult using
  JSR177.
 
  BlackBerry classic (which is built around Java) isn't supported by
  Cordova
  and hasn't been for a few releases.
  BlackBerry 10 is built around QNX.
 
  I'm not making a statement about implementability re BB10 (just
 that
  Java
  is irrelevant),
 
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
  l
 
  Is probably where someone would go to start...
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: WebView Promise and W3C standards

[Jesse]

Thanks Max,
Yeah, I saw my earlier comment, but given more time to think about it, I
feel that plugin-ization of all things is a better approach. ( my dislike
of promises aside )
Ultimately these apis will make their way into the browser controls
themselves, then plugin authors could drop their dependency and move on.

Also, once we move more firmly toward the browserify functionality, plugin
authors can simply use the npm published version of es6-promise and not
need to do anything at all.



@purplecabbage
risingj.com

On Fri, Dec 5, 2014 at 12:03 PM, Max Woghiren m...@chromium.org wrote:

 I can easily change to expanded (non-minified) code; I went with smaller
 size, expecting that people wouldn't be wanting to inspect the promise
 polyfill code.  No big deal.

 Earlier in this very thread, people (Jesse included) asserted that it
 should be in core, and Andrew outlined rationale.  I was trying to make
 progress on a task that seemed like a go-ahead and was then left hanging.
 If enough people believe it should be a plugin, then we can certainly go
 that way.  Looking forward to more input.

 On Fri, Dec 5, 2014 at 2:10 PM, Jesse purplecabb...@gmail.com wrote:

  We would be mandating its support, we have plenty of issues in Jira,
  and this solves none of them.
  ... and minified code? Why? How can I evaluate it?
 
  My mantra is and will remain Plugins are everything, and everything
  is a plugin
  What is the inconvenience in having a dependency on a promise plugin?
  I don't see the downside, and I think it would be perfect for those
  who want to use it.
 
  Personally I think we should be pushing the browserify functionality
  in cordova-js, and ripping stuff out, not adding it.
 
 
   On Dec 5, 2014, at 9:59 AM, Max Woghiren m...@chromium.org wrote:
  
   I think it's nice to remove that obstacle from in front of plugin
   developers who want to use promises.  If we're going to suggest that
  people
   drop the polyfill in themselves, I don't see the harm in just having it
   there, especially if we don't mandate its use.
  
   Going forward, many/most APIs will use promises; it might get a little
   unwieldy to have a whole bunch of plugins depend on a promise plugin.
  
   The bottom line, for me, is that this doesn't force anyone to use
  promises;
   it's just easy and there for those who want it.
  
   On Fri, Dec 5, 2014 at 12:11 PM, Jesse purplecabb...@gmail.com
 wrote:
  
   Nice, but please don't add this.
   Anyone who wants or needs this can do what you did, and if I start
  seeing
   promise code throughout Cordova.js I may run.
  
   We should be looking to get rid of Cordova.js entirely, not add more
  deps.
  
   Why not a promise plugin?
  
   Fyi: promises invoke my fight or flight response, and I have only
 found
   them useful for blocking contribution. That said, they already exist
 in
   windows8.1 as part of winjs.
  
  
   Sent from mobile
  
   On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org wrote:
  
   I've created a topic branch called promise
   
  
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/promise
  
   to cordova-js.  It has a commit that adds this ES6 promise polyfill
   https://github.com/jakearchibald/es6-promise (minified) to
  cordova.js
   and
   a simple test to ensure it's found.
  
   That's literally all it is right now—please take a look, though.
 Shall
   we
   move forward on this?
  
   On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins 
 br...@bryanhiggins.net
  
   wrote:
  
   BB10 does have a native secure element API. I may be able to dig up
  some
   code which bridges this to JavaScript.
  
  
   On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker 
 ignisvul...@gmail.com
   wrote:
  
   I created https://issues.apache.org/jira/browse/CB-7310 to track
  this.
  
  
   2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:
  
   Good to know. Thanks.
   Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:
  
   Axel Nennker wrote:
   I am interested to implement the secure element API.
   Mozilla is currently implementing it with our help for FFOS but
 I
   want
   it
   for Android too. Blackberry shouldn't be that difficult using
   JSR177.
  
   BlackBerry classic (which is built around Java) isn't supported
 by
   Cordova
   and hasn't been for a few releases.
   BlackBerry 10 is built around QNX.
  
   I'm not making a statement about implementability re BB10 (just
  that
   Java
   is irrelevant),
  
 
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
   l
  
   Is probably where someone would go to start...
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For 

Re: WebView Promise and W3C standards

[Ian Clelland]

I have two reasons for not wanting this as a plugin (both of which, I'm
sure, are entirely subjective)

The biggest one is just that native support for this really is coming
quickly, and one day, we'll be able to remove it, because just about every
platform that we care about will have support built in. Those that don't
can have the polyfill included as part of *their* cordova.js, and the
modern platforms can run without it.

If, by the time we get there, there are a hundred plugins that all depend
on org.apache.cordova.promise, then we have no choice but to maintain that
plugin, and we have to tell people to include it, and depend on it, even
when 95% of devices have native support. On the other hand, when we stop
supporting iOS 7, if we have included the polyfill in cordova-ios.js, then
we just remove it, and nothing at all changes for anyone else. Plugin
developers, application developers, even core Cordova developers who have
been relying on the polyfill for support, just see everything continue to
work, and Cordova is lighter as a result.

The second reason is that I can already see things in Cordova itself that
I'd like to write in a promise style. I'd love to replace the deviceready
event with something like

cordova.deviceReady().then(function() {
do stuff
}, function() {
  handle error
});

and even

cordova.exec(Plugin, arguments).then(successCallback).;

This requires support before plugins load, though. (And I accept that not
everyone is going to agree with the design)


On Fri Dec 05 2014 at 3:04:46 PM Max Woghiren m...@chromium.org wrote:

 I can easily change to expanded (non-minified) code; I went with smaller
 size, expecting that people wouldn't be wanting to inspect the promise
 polyfill code.  No big deal.

 Earlier in this very thread, people (Jesse included) asserted that it
 should be in core, and Andrew outlined rationale.  I was trying to make
 progress on a task that seemed like a go-ahead and was then left hanging.
 If enough people believe it should be a plugin, then we can certainly go
 that way.  Looking forward to more input.

 On Fri, Dec 5, 2014 at 2:10 PM, Jesse purplecabb...@gmail.com wrote:

  We would be mandating its support, we have plenty of issues in Jira,
  and this solves none of them.
  ... and minified code? Why? How can I evaluate it?
 
  My mantra is and will remain Plugins are everything, and everything
  is a plugin
  What is the inconvenience in having a dependency on a promise plugin?
  I don't see the downside, and I think it would be perfect for those
  who want to use it.
 
  Personally I think we should be pushing the browserify functionality
  in cordova-js, and ripping stuff out, not adding it.
 
 
   On Dec 5, 2014, at 9:59 AM, Max Woghiren m...@chromium.org wrote:
  
   I think it's nice to remove that obstacle from in front of plugin
   developers who want to use promises.  If we're going to suggest that
  people
   drop the polyfill in themselves, I don't see the harm in just having it
   there, especially if we don't mandate its use.
  
   Going forward, many/most APIs will use promises; it might get a little
   unwieldy to have a whole bunch of plugins depend on a promise plugin.
  
   The bottom line, for me, is that this doesn't force anyone to use
  promises;
   it's just easy and there for those who want it.
  
   On Fri, Dec 5, 2014 at 12:11 PM, Jesse purplecabb...@gmail.com
 wrote:
  
   Nice, but please don't add this.
   Anyone who wants or needs this can do what you did, and if I start
  seeing
   promise code throughout Cordova.js I may run.
  
   We should be looking to get rid of Cordova.js entirely, not add more
  deps.
  
   Why not a promise plugin?
  
   Fyi: promises invoke my fight or flight response, and I have only
 found
   them useful for blocking contribution. That said, they already exist
 in
   windows8.1 as part of winjs.
  
  
   Sent from mobile
  
   On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org wrote:
  
   I've created a topic branch called promise
   
  
  https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=
 shortlog;h=refs/heads/promise
  
   to cordova-js.  It has a commit that adds this ES6 promise polyfill
   https://github.com/jakearchibald/es6-promise (minified) to
  cordova.js
   and
   a simple test to ensure it's found.
  
   That's literally all it is right now—please take a look, though.
 Shall
   we
   move forward on this?
  
   On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins 
 br...@bryanhiggins.net
  
   wrote:
  
   BB10 does have a native secure element API. I may be able to dig up
  some
   code which bridges this to JavaScript.
  
  
   On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker 
 ignisvul...@gmail.com
   wrote:
  
   I created https://issues.apache.org/jira/browse/CB-7310 to track
  this.
  
  
   2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:
  
   Good to know. Thanks.
   Am 13.08.2014 20:56 schrieb Josh Soref 

Re: WebView Promise and W3C standards

[Brian LeRoux]

This has me more convinced it should be a userland library and not even a
plugin. Problem solved! ;)

On Fri, Dec 5, 2014, 12:28 PM Ian Clelland iclell...@chromium.org wrote:

 I have two reasons for not wanting this as a plugin (both of which, I'm
 sure, are entirely subjective)

 The biggest one is just that native support for this really is coming
 quickly, and one day, we'll be able to remove it, because just about every
 platform that we care about will have support built in. Those that don't
 can have the polyfill included as part of *their* cordova.js, and the
 modern platforms can run without it.

 If, by the time we get there, there are a hundred plugins that all depend
 on org.apache.cordova.promise, then we have no choice but to maintain that
 plugin, and we have to tell people to include it, and depend on it, even
 when 95% of devices have native support. On the other hand, when we stop
 supporting iOS 7, if we have included the polyfill in cordova-ios.js, then
 we just remove it, and nothing at all changes for anyone else. Plugin
 developers, application developers, even core Cordova developers who have
 been relying on the polyfill for support, just see everything continue to
 work, and Cordova is lighter as a result.

 The second reason is that I can already see things in Cordova itself that
 I'd like to write in a promise style. I'd love to replace the deviceready
 event with something like

 cordova.deviceReady().then(function() {
 do stuff
 }, function() {
   handle error
 });

 and even

 cordova.exec(Plugin, arguments).then(successCallback).;

 This requires support before plugins load, though. (And I accept that not
 everyone is going to agree with the design)


 On Fri Dec 05 2014 at 3:04:46 PM Max Woghiren m...@chromium.org wrote:

  I can easily change to expanded (non-minified) code; I went with smaller
  size, expecting that people wouldn't be wanting to inspect the promise
  polyfill code.  No big deal.
 
  Earlier in this very thread, people (Jesse included) asserted that it
  should be in core, and Andrew outlined rationale.  I was trying to make
  progress on a task that seemed like a go-ahead and was then left hanging.
  If enough people believe it should be a plugin, then we can certainly go
  that way.  Looking forward to more input.
 
  On Fri, Dec 5, 2014 at 2:10 PM, Jesse purplecabb...@gmail.com wrote:
 
   We would be mandating its support, we have plenty of issues in Jira,
   and this solves none of them.
   ... and minified code? Why? How can I evaluate it?
  
   My mantra is and will remain Plugins are everything, and everything
   is a plugin
   What is the inconvenience in having a dependency on a promise plugin?
   I don't see the downside, and I think it would be perfect for those
   who want to use it.
  
   Personally I think we should be pushing the browserify functionality
   in cordova-js, and ripping stuff out, not adding it.
  
  
On Dec 5, 2014, at 9:59 AM, Max Woghiren m...@chromium.org wrote:
   
I think it's nice to remove that obstacle from in front of plugin
developers who want to use promises.  If we're going to suggest that
   people
drop the polyfill in themselves, I don't see the harm in just having
 it
there, especially if we don't mandate its use.
   
Going forward, many/most APIs will use promises; it might get a
 little
unwieldy to have a whole bunch of plugins depend on a promise plugin.
   
The bottom line, for me, is that this doesn't force anyone to use
   promises;
it's just easy and there for those who want it.
   
On Fri, Dec 5, 2014 at 12:11 PM, Jesse purplecabb...@gmail.com
  wrote:
   
Nice, but please don't add this.
Anyone who wants or needs this can do what you did, and if I start
   seeing
promise code throughout Cordova.js I may run.
   
We should be looking to get rid of Cordova.js entirely, not add more
   deps.
   
Why not a promise plugin?
   
Fyi: promises invoke my fight or flight response, and I have only
  found
them useful for blocking contribution. That said, they already exist
  in
windows8.1 as part of winjs.
   
   
Sent from mobile
   
On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org
 wrote:
   
I've created a topic branch called promise

   
   https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=
  shortlog;h=refs/heads/promise
   
to cordova-js.  It has a commit that adds this ES6 promise polyfill
https://github.com/jakearchibald/es6-promise (minified) to
   cordova.js
and
a simple test to ensure it's found.
   
That's literally all it is right now—please take a look, though.
  Shall
we
move forward on this?
   
On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins 
  br...@bryanhiggins.net
   
wrote:
   
BB10 does have a native secure element API. I may be able to dig
 up
   some
code which bridges this to JavaScript.
   
   
On Thu, Aug 

Re: WebView Promise and W3C standards

[Joe Bowser]

+1 to userland. I see other approaches causing more problems.

BTW: The only time I use promises is when the platform explicitly requires
it, and right now that's just MozillaView.  While I think it looks awesome,
I view Promises as a luxury right now and not a standard feature as of yet.

I also really wish specs wouldn't rely on code that only exists on the very
latest browsers. It just makes life harder on people who have to implement
stuff.

Re: WebView Promise and W3C standards

[Axel Nennker]

I created https://issues.apache.org/jira/browse/CB-7310 to track this.


2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:

 Good to know. Thanks.
  Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:

 Axel Nennker wrote:
 I am interested to implement the secure element API.
 Mozilla is currently implementing it with our help for FFOS but I want it
 for Android too. Blackberry shouldn't be that difficult using JSR177.

 BlackBerry classic (which is built around Java) isn't supported by Cordova
 and hasn't been for a few releases.
 BlackBerry 10 is built around QNX.

 I'm not making a statement about implementability re BB10 (just that Java
 is irrelevant),

 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
 l

 Is probably where someone would go to start...

Re: WebView Promise and W3C standards

[Bryan Higgins]

BB10 does have a native secure element API. I may be able to dig up some
code which bridges this to JavaScript.


On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker ignisvul...@gmail.com wrote:

 I created https://issues.apache.org/jira/browse/CB-7310 to track this.


 2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:

  Good to know. Thanks.
   Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:
 
  Axel Nennker wrote:
  I am interested to implement the secure element API.
  Mozilla is currently implementing it with our help for FFOS but I want
 it
  for Android too. Blackberry shouldn't be that difficult using JSR177.
 
  BlackBerry classic (which is built around Java) isn't supported by
 Cordova
  and hasn't been for a few releases.
  BlackBerry 10 is built around QNX.
 
  I'm not making a statement about implementability re BB10 (just that
 Java
  is irrelevant),
 
 
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
  l
 
  Is probably where someone would go to start...
 
 

WebView Promise and W3C standards

[Axel Nennker]

Hi,

newer W3C standards use Promises but I think that Promises are not
implemented in the WebViews Cordova currently uses.

Any advise on this? How should I implement a new W3C standard in Cordova?
Are there examples already?

kind regards
Axel

Re: WebView Promise and W3C standards

[Michal Mocny]

Libs like modernizr will polyfill Promises, but that seems heavy handed for
just this small library.

My advice: when we want to write our first api that requires promises, we
create a separate plugin just for the Promise polyfill.  Then, any api that
requires Promises can depend on the polyfill plugin.  We've been using this
strategy for cca and has worked really well.

-Michal


On Wed, Aug 13, 2014 at 4:56 AM, Axel Nennker ignisvul...@gmail.com wrote:

 Hi,

 newer W3C standards use Promises but I think that Promises are not
 implemented in the WebViews Cordova currently uses.

 Any advise on this? How should I implement a new W3C standard in Cordova?
 Are there examples already?

 kind regards
 Axel

Re: WebView Promise and W3C standards

[Andrew Grieve]

I'm be in favour of adding the polyfill right to cordova.js.

- I'd like to use setImmediate within the Android bridge code, and
setImmediate make up about half of the Promise polyfill code.
- The polyfill is quite small
- Promises are a part of ECMAScript, have been adopted by multiple
browsers, and are being used in several up-and-coming specs (service
workers, file)
- If we make it a part of core, we can start encouraging devs to write
plugins that return them.


On Wed, Aug 13, 2014 at 8:29 AM, Michal Mocny mmo...@chromium.org wrote:

 Libs like modernizr will polyfill Promises, but that seems heavy handed for
 just this small library.

 My advice: when we want to write our first api that requires promises, we
 create a separate plugin just for the Promise polyfill.  Then, any api that
 requires Promises can depend on the polyfill plugin.  We've been using this
 strategy for cca and has worked really well.

 -Michal


 On Wed, Aug 13, 2014 at 4:56 AM, Axel Nennker ignisvul...@gmail.com
 wrote:

  Hi,
 
  newer W3C standards use Promises but I think that Promises are not
  implemented in the WebViews Cordova currently uses.
 
  Any advise on this? How should I implement a new W3C standard in Cordova?
  Are there examples already?
 
  kind regards
  Axel
 

Re: WebView Promise and W3C standards

[Jesse]

I agree the polyfil should exist, and it should probably be in core.
However, I do not agree with the sentiment that 'we' should encourage their
use, 'you' may. Personally, I see more ugly code written because of
Promises than the ugly code it tries to fix.

Windows8 and Windows Phone 8 already support the Promise API because they
include WinJS.



@purplecabbage
risingj.com


On Wed, Aug 13, 2014 at 10:37 AM, Andrew Grieve agri...@chromium.org
wrote:

 I'm be in favour of adding the polyfill right to cordova.js.

 - I'd like to use setImmediate within the Android bridge code, and
 setImmediate make up about half of the Promise polyfill code.
 - The polyfill is quite small
 - Promises are a part of ECMAScript, have been adopted by multiple
 browsers, and are being used in several up-and-coming specs (service
 workers, file)
 - If we make it a part of core, we can start encouraging devs to write
 plugins that return them.


 On Wed, Aug 13, 2014 at 8:29 AM, Michal Mocny mmo...@chromium.org wrote:

  Libs like modernizr will polyfill Promises, but that seems heavy handed
 for
  just this small library.
 
  My advice: when we want to write our first api that requires promises, we
  create a separate plugin just for the Promise polyfill.  Then, any api
 that
  requires Promises can depend on the polyfill plugin.  We've been using
 this
  strategy for cca and has worked really well.
 
  -Michal
 
 
  On Wed, Aug 13, 2014 at 4:56 AM, Axel Nennker ignisvul...@gmail.com
  wrote:
 
   Hi,
  
   newer W3C standards use Promises but I think that Promises are not
   implemented in the WebViews Cordova currently uses.
  
   Any advise on this? How should I implement a new W3C standard in
 Cordova?
   Are there examples already?
  
   kind regards
   Axel
  
 

Re: WebView Promise and W3C standards

[Joe Bowser]

+1 on promises leading to worse JS code. I really wish that the Battery
Spec and others wouldn't use promises, since they're absolutely terrible
and events accomplish the same thing in that case.


On Wed, Aug 13, 2014 at 11:05 AM, Jesse purplecabb...@gmail.com wrote:

 I agree the polyfil should exist, and it should probably be in core.
 However, I do not agree with the sentiment that 'we' should encourage their
 use, 'you' may. Personally, I see more ugly code written because of
 Promises than the ugly code it tries to fix.

 Windows8 and Windows Phone 8 already support the Promise API because they
 include WinJS.



 @purplecabbage
 risingj.com


 On Wed, Aug 13, 2014 at 10:37 AM, Andrew Grieve agri...@chromium.org
 wrote:

  I'm be in favour of adding the polyfill right to cordova.js.
 
  - I'd like to use setImmediate within the Android bridge code, and
  setImmediate make up about half of the Promise polyfill code.
  - The polyfill is quite small
  - Promises are a part of ECMAScript, have been adopted by multiple
  browsers, and are being used in several up-and-coming specs (service
  workers, file)
  - If we make it a part of core, we can start encouraging devs to write
  plugins that return them.
 
 
  On Wed, Aug 13, 2014 at 8:29 AM, Michal Mocny mmo...@chromium.org
 wrote:
 
   Libs like modernizr will polyfill Promises, but that seems heavy handed
  for
   just this small library.
  
   My advice: when we want to write our first api that requires promises,
 we
   create a separate plugin just for the Promise polyfill.  Then, any api
  that
   requires Promises can depend on the polyfill plugin.  We've been using
  this
   strategy for cca and has worked really well.
  
   -Michal
  
  
   On Wed, Aug 13, 2014 at 4:56 AM, Axel Nennker ignisvul...@gmail.com
   wrote:
  
Hi,
   
newer W3C standards use Promises but I think that Promises are not
implemented in the WebViews Cordova currently uses.
   
Any advise on this? How should I implement a new W3C standard in
  Cordova?
Are there examples already?
   
kind regards
Axel
   
  
 

Re: WebView Promise and W3C standards

[Axel Nennker]

I am interested to implement the secure element API.
Mozilla is currently implementing it with our help for FFOS but I want it
for Android too. Blackberry shouldn't be that difficult using JSR177.

https://bugzilla.mozilla.org/show_bug.cgi?id=879861

That API uses Promises.
Would be cool to have Promises in core.

Axel
 I agree the polyfil should exist, and it should probably be in core.
However, I do not agree with the sentiment that 'we' should encourage their
use, 'you' may. Personally, I see more ugly code written because of
Promises than the ugly code it tries to fix.

Windows8 and Windows Phone 8 already support the Promise API because they
include WinJS.



@purplecabbage
risingj.com


On Wed, Aug 13, 2014 at 10:37 AM, Andrew Grieve agri...@chromium.org
wrote:

 I'm be in favour of adding the polyfill right to cordova.js.

 - I'd like to use setImmediate within the Android bridge code, and
 setImmediate make up about half of the Promise polyfill code.
 - The polyfill is quite small
 - Promises are a part of ECMAScript, have been adopted by multiple
 browsers, and are being used in several up-and-coming specs (service
 workers, file)
 - If we make it a part of core, we can start encouraging devs to write
 plugins that return them.


 On Wed, Aug 13, 2014 at 8:29 AM, Michal Mocny mmo...@chromium.org wrote:

  Libs like modernizr will polyfill Promises, but that seems heavy handed
 for
  just this small library.
 
  My advice: when we want to write our first api that requires promises,
we
  create a separate plugin just for the Promise polyfill.  Then, any api
 that
  requires Promises can depend on the polyfill plugin.  We've been using
 this
  strategy for cca and has worked really well.
 
  -Michal
 
 
  On Wed, Aug 13, 2014 at 4:56 AM, Axel Nennker ignisvul...@gmail.com
  wrote:
 
   Hi,
  
   newer W3C standards use Promises but I think that Promises are not
   implemented in the WebViews Cordova currently uses.
  
   Any advise on this? How should I implement a new W3C standard in
 Cordova?
   Are there examples already?
  
   kind regards
   Axel
  
 

Re: WebView Promise and W3C standards

[Josh Soref]

Axel Nennker wrote:
I am interested to implement the secure element API.
Mozilla is currently implementing it with our help for FFOS but I want it
for Android too. Blackberry shouldn't be that difficult using JSR177.

BlackBerry classic (which is built around Java) isn't supported by Cordova
and hasn't been for a few releases.
BlackBerry 10 is built around QNX.

I'm not making a statement about implementability re BB10 (just that Java
is irrelevant),
https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
l

Is probably where someone would go to start...

Re: WebView Promise and W3C standards

[Axel Nennker]

Good to know. Thanks.
 Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:

 Axel Nennker wrote:
 I am interested to implement the secure element API.
 Mozilla is currently implementing it with our help for FFOS but I want it
 for Android too. Blackberry shouldn't be that difficult using JSR177.

 BlackBerry classic (which is built around Java) isn't supported by Cordova
 and hasn't been for a few releases.
 BlackBerry 10 is built around QNX.

 I'm not making a statement about implementability re BB10 (just that Java
 is irrelevant),
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
 l

 Is probably where someone would go to start...