This has me more convinced it should be a userland library and not even a
plugin. Problem solved! ;)
On Fri, Dec 5, 2014, 12:28 PM Ian Clelland <iclell...@chromium.org> wrote:
> I have two reasons for not wanting this as a plugin (both of which, I'm
> sure, are entirely subjective)
>
> The biggest one is just that native support for this really is coming
> quickly, and one day, we'll be able to remove it, because just about every
> platform that we care about will have support built in. Those that don't
> can have the polyfill included as part of *their* cordova.js, and the
> modern platforms can run without it.
>
> If, by the time we get there, there are a hundred plugins that all depend
> on org.apache.cordova.promise, then we have no choice but to maintain that
> plugin, and we have to tell people to include it, and depend on it, even
> when 95% of devices have native support. On the other hand, when we stop
> supporting iOS 7, if we have included the polyfill in cordova-ios.js, then
> we just remove it, and nothing at all changes for anyone else. Plugin
> developers, application developers, even core Cordova developers who have
> been relying on the polyfill for support, just see everything continue to
> work, and Cordova is lighter as a result.
>
> The second reason is that I can already see things in Cordova itself that
> I'd like to write in a promise style. I'd love to replace the deviceready
> event with something like
>
> cordova.deviceReady().then(function() {
> do stuff
> }, function() {
> handle error
> });
>
> and even
>
> cordova.exec(Plugin, arguments).then(successCallback).;
>
> This requires support before plugins load, though. (And I accept that not
> everyone is going to agree with the design)
>
>
> On Fri Dec 05 2014 at 3:04:46 PM Max Woghiren <m...@chromium.org> wrote:
>
> > I can easily change to expanded (non-minified) code; I went with smaller
> > size, expecting that people wouldn't be wanting to inspect the promise
> > polyfill code. No big deal.
> >
> > Earlier in this very thread, people (Jesse included) asserted that it
> > should be in core, and Andrew outlined rationale. I was trying to make
> > progress on a task that seemed like a go-ahead and was then left hanging.
> > If enough people believe it should be a plugin, then we can certainly go
> > that way. Looking forward to more input.
> >
> > On Fri, Dec 5, 2014 at 2:10 PM, Jesse <purplecabb...@gmail.com> wrote:
> >
> > > We would be mandating its support, we have plenty of issues in Jira,
> > > and this solves none of them.
> > > ... and minified code? Why? How can I evaluate it?
> > >
> > > My mantra is and will remain "Plugins are everything, and everything
> > > is a plugin"
> > > What is the inconvenience in having a dependency on a promise plugin?
> > > I don't see the downside, and I think it would be perfect for those
> > > who want to use it.
> > >
> > > Personally I think we should be pushing the browserify functionality
> > > in cordova-js, and ripping stuff out, not adding it.
> > >
> > >
> > > > On Dec 5, 2014, at 9:59 AM, Max Woghiren <m...@chromium.org> wrote:
> > > >
> > > > I think it's nice to remove that obstacle from in front of plugin
> > > > developers who want to use promises. If we're going to suggest that
> > > people
> > > > drop the polyfill in themselves, I don't see the harm in just having
> it
> > > > there, especially if we don't mandate its use.
> > > >
> > > > Going forward, many/most APIs will use promises; it might get a
> little
> > > > unwieldy to have a whole bunch of plugins depend on a promise plugin.
> > > >
> > > > The bottom line, for me, is that this doesn't force anyone to use
> > > promises;
> > > > it's just easy and there for those who want it.
> > > >
> > > >> On Fri, Dec 5, 2014 at 12:11 PM, Jesse <purplecabb...@gmail.com>
> > wrote:
> > > >>
> > > >> Nice, but please don't add this.
> > > >> Anyone who wants or needs this can do what you did, and if I start
> > > seeing
> > > >> promise code throughout Cordova.js I may run.
> > > >>
> > > >> We should be looking to get rid of Cordova.js entirely, not add more
> > > deps.
> > > >>
> > > >> Why not a promise plugin?
> > > >>
> > > >> Fyi: promises invoke my fight or flight response, and I have only
> > found
> > > >> them useful for blocking contribution. That said, they already exist
> > in
> > > >> windows8.1 as part of winjs.
> > > >>
> > > >>
> > > >> Sent from mobile
> > > >>
> > > >>> On Dec 5, 2014, at 8:40 AM, Max Woghiren <m...@chromium.org>
> wrote:
> > > >>>
> > > >>> I've created a topic branch called "promise"
> > > >>> <
> > > >>
> > > https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=
> > shortlog;h=refs/heads/promise
> > > >>>
> > > >>> to cordova-js. It has a commit that adds this ES6 promise polyfill
> > > >>> <https://github.com/jakearchibald/es6-promise> (minified) to
> > > cordova.js
> > > >> and
> > > >>> a simple test to ensure it's found.
> > > >>>
> > > >>> That's literally all it is right now—please take a look, though.
> > Shall
> > > >> we
> > > >>> move forward on this?
> > > >>>
> > > >>> On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins <
> > br...@bryanhiggins.net
> > > >
> > > >>> wrote:
> > > >>>
> > > >>>> BB10 does have a native secure element API. I may be able to dig
> up
> > > some
> > > >>>> code which bridges this to JavaScript.
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Aug 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
> > >
> > >
> >
>
