WebView Promise and W3C standards

[Axel Nennker <ig...@gmail.com>]

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

[Brian LeRoux <b...@brian.io>]

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 <pu...@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 <ma...@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 <pu...@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 <ma...@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 <bryan@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 <ig...@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 <ig...@gmail.com>:
> >>>>>
> >>>>>> Good to know. Thanks.
> >>>>>> Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: WebView Promise and W3C standards

[Jesse <pu...@gmail.com>]

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 <ma...@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 <pu...@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 <ma...@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 <pu...@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 <ma...@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 <
> bryan@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 <
> ignisvulpis@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 <ig...@gmail.com>:
> > >>>>>
> > >>>>>> Good to know. Thanks.
> > >>>>>> Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>

Re: WebView Promise and W3C standards

[Jesse <pu...@gmail.com>]

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 <mm...@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 <mm...@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 <pu...@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 <
> agrieve@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 <
> > > iclelland@chromium.org
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> > > > agrieve@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 <
> bowserj@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

[Sebastien Blanc <sc...@gmail.com>]

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 <mm...@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 <ag...@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 <mm...@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 <
> mmocny@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 <pu...@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 <
> > > > agrieve@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 <
> > > > > > iclelland@chromium.org
> > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> > > > > > > agrieve@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 <
> > > > bowserj@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 <mm...@chromium.org>]

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 <ag...@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 <mm...@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 <mm...@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 <pu...@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 <
> > > agrieve@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 <
> > > > > iclelland@chromium.org
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> > > > > > agrieve@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 <
> > > bowserj@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 <b...@brian.io>]

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 <pu...@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 <ag...@chromium.org>
> wrote:
> >
> >> On Fri, Dec 12, 2014 at 2:28 PM, Jesse <pu...@gmail.com> wrote:
> >>
> >>> On Fri, Dec 12, 2014 at 11:10 AM, Shazron <sh...@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 <ag...@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 <pu...@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 <ag...@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 <
> >> agrieve@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 <
> >> mmocny@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 <
> >>> mmocny@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 <
> >> purplecabbage@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 <
> >>>>>>>>> agrieve@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 <
> >>>>>>>>>>> iclelland@chromium.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> >>>>>>>>>>>> agrieve@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 <
> >>>>>>>>> bowserj@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.
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: WebView Promise and W3C standards

[Jesse <pu...@gmail.com>]

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 <ag...@chromium.org> wrote:
> 
>> On Fri, Dec 12, 2014 at 2:28 PM, Jesse <pu...@gmail.com> wrote:
>> 
>>> On Fri, Dec 12, 2014 at 11:10 AM, Shazron <sh...@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 <ag...@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 <pu...@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 <ag...@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 <
>> agrieve@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 <
>> mmocny@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 <
>>> mmocny@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 <
>> purplecabbage@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 <
>>>>>>>>> agrieve@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 <
>>>>>>>>>>> iclelland@chromium.org
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
>>>>>>>>>>>> agrieve@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 <
>>>>>>>>> bowserj@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.
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> 

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

Re: WebView Promise and W3C standards

[Andrew Grieve <ag...@chromium.org>]

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

> On Fri, Dec 12, 2014 at 11:10 AM, Shazron <sh...@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 <ag...@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 <pu...@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 <ag...@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 <
> agrieve@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 <
> mmocny@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 <
> > mmocny@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 <
> purplecabbage@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 <
> > >> >>>> agrieve@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 <
> > >> >>>>>> iclelland@chromium.org
> > >> >>>>>>>>
> > >> >>>>>>>>> wrote:
> > >> >>>>>>>>>
> > >> >>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> > >> >>>>>>> agrieve@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 <
> > >> >>>> bowserj@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.
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>

Re: WebView Promise and W3C standards

[Jesse <pu...@gmail.com>]

On Fri, Dec 12, 2014 at 11:10 AM, Shazron <sh...@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 <ag...@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 <pu...@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 <ag...@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 <agrieve@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 <mmocny@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 <
> mmocny@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 <pu...@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 <
> >> >>>> agrieve@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 <
> >> >>>>>> iclelland@chromium.org
> >> >>>>>>>>
> >> >>>>>>>>> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> >> >>>>>>> agrieve@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 <
> >> >>>> bowserj@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.
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: WebView Promise and W3C standards

[Shazron <sh...@gmail.com>]

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

On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve <ag...@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 <pu...@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 <ag...@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 <ag...@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 <mm...@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 <mm...@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 <pu...@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 <
>> >>>> agrieve@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 <
>> >>>>>> iclelland@chromium.org
>> >>>>>>>>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
>> >>>>>>> agrieve@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 <
>> >>>> bowserj@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.
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>

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

Re: WebView Promise and W3C standards

[Andrew Grieve <ag...@chromium.org>]

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 <pu...@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 <ag...@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 <ag...@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 <mm...@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 <mm...@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 <pu...@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 <
> >>>> agrieve@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 <
> >>>>>> iclelland@chromium.org
> >>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> >>>>>>> agrieve@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 <
> >>>> bowserj@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.
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: WebView Promise and W3C standards

[Jesse <pu...@gmail.com>]

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 <ag...@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 <ag...@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 <mm...@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 <mm...@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 <pu...@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 <
>>>> agrieve@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 <
>>>>>> iclelland@chromium.org
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
>>>>>>> agrieve@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 <
>>>> bowserj@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.
>>

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

Re: WebView Promise and W3C standards

[Andrew Grieve <ag...@chromium.org>]

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 <ag...@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 <mm...@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 <mm...@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 <pu...@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 <
> > > agrieve@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 <
> > > > > iclelland@chromium.org
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> > > > > > agrieve@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 <
> > > bowserj@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 <b...@brian.io>]

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 <ag...@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 <mm...@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 <mm...@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 <pu...@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 <
> > agrieve@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 <
> > > > iclelland@chromium.org
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> > > > > agrieve@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 <
> > bowserj@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 <ag...@chromium.org>]

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 <mm...@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 <mm...@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 <pu...@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 <
> agrieve@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 <
> > > iclelland@chromium.org
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> > > > agrieve@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 <
> bowserj@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 <mm...@chromium.org>]

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 <mm...@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 <pu...@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 <agrieve@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 <
> > iclelland@chromium.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> > > agrieve@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 <bo...@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 <b...@brian.io>]

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 <mm...@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 <pu...@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 <ag...@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 <
> iclelland@chromium.org
> > >
> > > > wrote:
> > > >
> > > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> > agrieve@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 <bo...@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 <mm...@chromium.org>]

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 <pu...@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 <ag...@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 <iclelland@chromium.org
> >
> > > wrote:
> > >
> > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> agrieve@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 <bo...@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 <pu...@gmail.com>]

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 <ag...@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 <ic...@chromium.org>
> > wrote:
> >
> > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <ag...@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 <bo...@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 <b...@brian.io>]

- 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 <ag...@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 <ic...@chromium.org>
> wrote:
>
> > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <ag...@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 <bo...@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 <ag...@chromium.org>]

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 <ic...@chromium.org>
wrote:

> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <ag...@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 <bo...@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 <ic...@chromium.org>]

On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <ag...@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 <bo...@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 <ag...@chromium.org>]

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 <bo...@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

[Joe Bowser <bo...@gmail.com>]

+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 <b...@brian.io>]

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 <ic...@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 <ma...@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 <pu...@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 <ma...@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 <pu...@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 <ma...@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 <
> > bryan@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 <
> > ignisvulpis@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 <ig...@gmail.com>:
> > > >>>>>
> > > >>>>>> Good to know. Thanks.
> > > >>>>>> Am 13.08.2014 20:56 schrieb "Josh Soref" <jsoref@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-unsubscribe@cordova.apache.org
> > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
> >
>

Re: WebView Promise and W3C standards

[Ian Clelland <ic...@chromium.org>]

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 <ma...@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 <pu...@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 <ma...@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 <pu...@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 <ma...@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 <
> bryan@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 <
> ignisvulpis@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 <ig...@gmail.com>:
> > >>>>>
> > >>>>>> Good to know. Thanks.
> > >>>>>> Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>

Re: WebView Promise and W3C standards

[Max Woghiren <ma...@chromium.org>]

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 <pu...@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 <ma...@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 <pu...@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 <ma...@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 <bryan@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 <ig...@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 <ig...@gmail.com>:
> >>>>>
> >>>>>> Good to know. Thanks.
> >>>>>> Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: WebView Promise and W3C standards

[Jesse <pu...@gmail.com>]

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 <ma...@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 <pu...@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 <ma...@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 <ig...@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 <ig...@gmail.com>:
>>>>>
>>>>>> Good to know. Thanks.
>>>>>> Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>

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

Re: WebView Promise and W3C standards

[Max Woghiren <ma...@chromium.org>]

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 <pu...@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 <ma...@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 <ig...@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 <ig...@gmail.com>:
> >>>
> >>>> Good to know. Thanks.
> >>>> Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: WebView Promise and W3C standards

[Jesse <pu...@gmail.com>]

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 <ma...@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 <ig...@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 <ig...@gmail.com>:
>>> 
>>>> Good to know. Thanks.
>>>> Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Re: WebView Promise and W3C standards

[Max Woghiren <ma...@chromium.org>]

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 <ig...@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 <ig...@gmail.com>:
> >
> > > Good to know. Thanks.
> > >  Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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 <br...@bryanhiggins.net>]

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 <ig...@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 <ig...@gmail.com>:
>
> > Good to know. Thanks.
> >  Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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

[Axel Nennker <ig...@gmail.com>]

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


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

> Good to know. Thanks.
>  Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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

[Axel Nennker <ig...@gmail.com>]

Good to know. Thanks.
 Am 13.08.2014 20:56 schrieb "Josh Soref" <js...@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

[Josh Soref <js...@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

[Axel Nennker <ig...@gmail.com>]

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 <ag...@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 <mm...@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 <ig...@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 <bo...@gmail.com>]

+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 <pu...@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 <ag...@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 <mm...@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 <ig...@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 <pu...@gmail.com>]

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 <ag...@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 <mm...@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 <ig...@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 <ag...@chromium.org>]

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 <mm...@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 <ig...@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

[Michal Mocny <mm...@chromium.org>]

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 <ig...@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
>