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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]> 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 <
> [email protected]
> > >
> > >>> 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 <
> [email protected]>
> > >>>> wrote:
> > >>>>
> > >>>>> I created https://issues.apache.org/jira/browse/CB-7310 to track
> > this.
> > >>>>>
> > >>>>>
> > >>>>> 2014-08-13 22:57 GMT+02:00 Axel Nennker <[email protected]>:
> > >>>>>
> > >>>>>> Good to know. Thanks.
> > >>>>>> Am 13.08.2014 20:56 schrieb "Josh Soref" <[email protected]>:
> > >>>>>>
> > >>>>>> 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: [email protected]
> > >> For additional commands, e-mail: [email protected]
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
