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