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