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