You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Paul Contat <co...@gmail.com> on 2015/07/01 09:38:26 UTC
Introduction
Hello everyone,
My name is Paul Contat, and I'm an engineering student and currently doing
an internship at W3C focusing on aligning cordova API with W3C ones where
applicable, as part of the HTML5Apps EU project (
http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
)
For my internship, I’m planning to contribute to the cordova project,
starting by the BatteryStatus API (
https://issues.apache.org/jira/browse/CB-6065) if it’s possible.
I've just signed the ICLA, created an account on Apache JIRA so I’m ready
to start and submitted my first pull request:
https://github.com/apache/cordova-plugin-battery-status/pull/24
I’m looking forward to feedback on whether I’m on the right path for
updating the Battery plugin API; I’m in particular interested to understand
if and how the current API should be deprecated once we get to a stage
where the new API is deemed in a good enough shape.
Best regards,
Paul
Re: Introduction
Posted by Steven Gill <st...@gmail.com>.
We decided to try github (cordova-discuss) out a while ago as a replacement
for google doc proposals we were using. This way we could revise a document
in one place and also not have to search around our email for the link to
the google doc. Proposals are supposed to be shared on the list when first
created and throughout the process when asking for feedback. Final decision
should always happen on the list. With google doc, a lot of the fine tuning
of the proposal happened in comments on the document. Now that fine tuning
is happening on the issue/PR.
I have seen links on our mailing list for both platformAPI and cordova-docs
proposals. You can view them at
https://github.com/cordova/cordova-discuss/pulls
We have also been using cordova github repo for a while now to draft and
get review on blog posts https://github.com/cordova/apache-blog-posts
On Tue, Jul 7, 2015 at 12:25 PM, Joe Bowser <bo...@gmail.com> wrote:
> When did we start discussing these proposals on GitHub instead of the dev
> list? That's kind of what the dev list is for, and I'm pretty sure it's not
> the Apache Way to do this.
>
> In fact, I wasn't aware that we were using our GitHub org for anything
> until now.
>
> On Tue, Jul 7, 2015, 12:01 PM julio cesar sanchez <jc...@gmail.com>
> wrote:
>
> It's only supported by android 5 webview (12% share right now), so I think
> the plugin makes sense for now even if it's going to be deprecated in the
> future and replaced by the browser battery status when more people have
> android 5 or greater
>
> But the discussion about this should be better on the cordova-discuss
> https <https://github.com/cordova/cordova-discuss/issues>://
> <https://github.com/cordova/cordova-discuss/issues>github.com
> <https://github.com/cordova/cordova-discuss/issues>/
> <https://github.com/cordova/cordova-discuss/issues>cordova
> <https://github.com/cordova/cordova-discuss/issues>/
> <https://github.com/cordova/cordova-discuss/issues>cordova-discuss
> <https://github.com/cordova/cordova-discuss/issues>/issues
> <https://github.com/cordova/cordova-discuss/issues>
>
> 2015-07-07 20:42 GMT+02:00 Joe Bowser <bo...@gmail.com>:
>
> > I hate to dash your hopes, but I think that we should probably not have a
> > Battery Status plugin and defer to browser behaviour on Android, since
> > Battery Status is supported on the browser with the latest Android
> > WebViews, and with Crosswalk. Any plugin should just be glue code for
> > facilitating this behaviour, similar to how we deprecated the Geolocation
> > plugin on Android in favour to Browser Geolocation.
> >
> > That's my two cents on the issue right now.
> >
> > On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote:
> >
> > > exactly so and by all means please feel free to use that, bluebird,
> rsvp,
> > > q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
> > >
> > > though I suggest one limits the scope to the other 200+ libraries
> > claiming
> > > A+ support! [2]
> > >
> > > ;P
> > >
> > > [1] https://www.npmjs.com/search?q=Promise
> > > [2] https://www.npmjs.com/search?q=Promise+A%2B
> > >
> > >
> > > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co>
> wrote:
> > >
> > > > I'd just like to mention that jQuery has promises built-in as the
> > > > $.Deferred object. It's not quite the same as the official Promises
> > spec,
> > > > but can be used similarly in most cases.
> > > >
> > > >
> > > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote:
> > > >>
> > > >> We experimented with Promise polyfills and had nothing but trouble.
> > I'd
> > > >> like to preface by saying: lets not get into a theory war. Some
> people
> > > like
> > > >> promises (fine) and some do not (also fine). My stance is that we
> > should
> > > >> leave that choice up to our end users.
> > > >>
> > > >> Lets throw some facts out to colour things.
> > > >>
> > > >> 1. Promises are a spec that will land in browsers natively [1]
> > > >> 2. Promises as a concept have MANY polyfill implementations
> > > >> 3. The polyfill landscape is largely divergent and implement
> different
> > > >> flavors of the concept
> > > >>
> > > >> Since we implement a User Agent we *could* polyfill to spec. As a
> > > plugin.
> > > >> (Jake's is probably best [2]) I'd be in favor of this and making
> that
> > > THE
> > > >> plugin dep for companion plugins that require Promises. The problem
> > with
> > > >> this is #3. If we have a window.Promise it could be clobbered by a
> > user
> > > >> that is not super aware of how things are composed under the hood.
> If
> > it
> > > >> *could* happen guess what: it will. Some frameworks even force the
> > idea
> > > of
> > > >> Promises that may not be totally on spec. Older jQuery and Ember
> come
> > to
> > > >> mind.
> > > >>
> > > >> The other way to solve this problem is patience. This is the path I
> am
> > > most
> > > >> in favor of. Lets wait out the native implementation to land in the
> > > various
> > > >> webviews and at such time we can start using those.
> > > >>
> > > >> Plugins really should wrap device and operating system API's (in my
> > > >> opinion) and we should leave library code for the user land to
> figure
> > > out.
> > > >> The Promise API *is a library* until such time as it has been
> > > implemented
> > > >> into the language runtimes natively (and not just speculatively
> > > >> standardized). Ok I guess faltered into the theory war part there.
> ;)
> > > >>
> > > >> [1] https://promisesaplus.com/
> > > >> [2] https://github.com/jakearchibald/es6-promise
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <muratsu@microsoft.com
> >
> > > wrote:
> > > >>
> > > >> Hey Paul,
> > > >>> Welcome to Cordova! I've looked at your changes on github and have
> > > some
> > > >>> early feedback.
> > > >>>
> > > >>> 1) As per spec you return a Promise on battery.js but to my
> > knowledge
> > > we
> > > >>> don't have a fallback for ES6 Promises on platforms that don't
> > > support it
> > > >>> yet. I would like to know what other committers think about this
> > > problem.
> > > >>> 2) I think the old API and the new API can co-exist for a while
> > > before we
> > > >>> deprecate and remove the old one. I see that the new spec uses a
> > > different
> > > >>> method name so we should be fine here.
> > > >>>
> > > >>> Thanks,
> > > >>> Murat
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: Paul Contat [mailto:contat.paul@gmail.com]
> > > >>> Sent: Wednesday, July 1, 2015 12:38 AM
> > > >>> To: dev@cordova.apache.org
> > > >>> Subject: Introduction
> > > >>>
> > > >>> Hello everyone,
> > > >>>
> > > >>> My name is Paul Contat, and I'm an engineering student and
> currently
> > > doing
> > > >>> an internship at W3C focusing on aligning cordova API with W3C
> ones
> > > where
> > > >>> applicable, as part of the HTML5Apps EU project (
> > > >>>
> > >
> >
>
> http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
> > > >>> )
> > > >>>
> > > >>> For my internship, I’m planning to contribute to the cordova
> > project,
> > > >>> starting by the BatteryStatus API (
> > > >>> https://issues.apache.org/jira/browse/CB-6065) if it’s possible.
> > > >>>
> > > >>> I've just signed the ICLA, created an account on Apache JIRA so
> I’m
> > > ready
> > > >>> to start and submitted my first pull request:
> > > >>> https://github.com/apache/cordova-plugin-battery-status/pull/24
> > > >>>
> > > >>> I’m looking forward to feedback on whether I’m on the right path
> for
> > > >>> updating the Battery plugin API; I’m in particular interested to
> > > understand
> > > >>> if and how the current API should be deprecated once we get to a
> > stage
> > > >>> where the new API is deemed in a good enough shape.
> > > >>>
> > > >>> Best regards,
> > > >>> Paul
> > > >>
> > > >>
> > > >>
> > > > --
> > > > Tyler Freeman
> > > > CTO, Tappur
> > > > http://tappur.co
> > > >
> > > > Sent from mobile
> > > >
> > >
> >
>
Re: Introduction
Posted by Joe Bowser <bo...@gmail.com>.
When did we start discussing these proposals on GitHub instead of the dev
list? That's kind of what the dev list is for, and I'm pretty sure it's not
the Apache Way to do this.
In fact, I wasn't aware that we were using our GitHub org for anything
until now.
On Tue, Jul 7, 2015, 12:01 PM julio cesar sanchez <jc...@gmail.com>
wrote:
It's only supported by android 5 webview (12% share right now), so I think
the plugin makes sense for now even if it's going to be deprecated in the
future and replaced by the browser battery status when more people have
android 5 or greater
But the discussion about this should be better on the cordova-discuss
https <https://github.com/cordova/cordova-discuss/issues>://
<https://github.com/cordova/cordova-discuss/issues>github.com
<https://github.com/cordova/cordova-discuss/issues>/
<https://github.com/cordova/cordova-discuss/issues>cordova
<https://github.com/cordova/cordova-discuss/issues>/
<https://github.com/cordova/cordova-discuss/issues>cordova-discuss
<https://github.com/cordova/cordova-discuss/issues>/issues
<https://github.com/cordova/cordova-discuss/issues>
2015-07-07 20:42 GMT+02:00 Joe Bowser <bo...@gmail.com>:
> I hate to dash your hopes, but I think that we should probably not have a
> Battery Status plugin and defer to browser behaviour on Android, since
> Battery Status is supported on the browser with the latest Android
> WebViews, and with Crosswalk. Any plugin should just be glue code for
> facilitating this behaviour, similar to how we deprecated the Geolocation
> plugin on Android in favour to Browser Geolocation.
>
> That's my two cents on the issue right now.
>
> On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote:
>
> > exactly so and by all means please feel free to use that, bluebird,
rsvp,
> > q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
> >
> > though I suggest one limits the scope to the other 200+ libraries
> claiming
> > A+ support! [2]
> >
> > ;P
> >
> > [1] https://www.npmjs.com/search?q=Promise
> > [2] https://www.npmjs.com/search?q=Promise+A%2B
> >
> >
> > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co> wrote:
> >
> > > I'd just like to mention that jQuery has promises built-in as the
> > > $.Deferred object. It's not quite the same as the official Promises
> spec,
> > > but can be used similarly in most cases.
> > >
> > >
> > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote:
> > >>
> > >> We experimented with Promise polyfills and had nothing but trouble.
> I'd
> > >> like to preface by saying: lets not get into a theory war. Some
people
> > like
> > >> promises (fine) and some do not (also fine). My stance is that we
> should
> > >> leave that choice up to our end users.
> > >>
> > >> Lets throw some facts out to colour things.
> > >>
> > >> 1. Promises are a spec that will land in browsers natively [1]
> > >> 2. Promises as a concept have MANY polyfill implementations
> > >> 3. The polyfill landscape is largely divergent and implement
different
> > >> flavors of the concept
> > >>
> > >> Since we implement a User Agent we *could* polyfill to spec. As a
> > plugin.
> > >> (Jake's is probably best [2]) I'd be in favor of this and making that
> > THE
> > >> plugin dep for companion plugins that require Promises. The problem
> with
> > >> this is #3. If we have a window.Promise it could be clobbered by a
> user
> > >> that is not super aware of how things are composed under the hood. If
> it
> > >> *could* happen guess what: it will. Some frameworks even force the
> idea
> > of
> > >> Promises that may not be totally on spec. Older jQuery and Ember come
> to
> > >> mind.
> > >>
> > >> The other way to solve this problem is patience. This is the path I
am
> > most
> > >> in favor of. Lets wait out the native implementation to land in the
> > various
> > >> webviews and at such time we can start using those.
> > >>
> > >> Plugins really should wrap device and operating system API's (in my
> > >> opinion) and we should leave library code for the user land to figure
> > out.
> > >> The Promise API *is a library* until such time as it has been
> > implemented
> > >> into the language runtimes natively (and not just speculatively
> > >> standardized). Ok I guess faltered into the theory war part there. ;)
> > >>
> > >> [1] https://promisesaplus.com/
> > >> [2] https://github.com/jakearchibald/es6-promise
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <mu...@microsoft.com>
> > wrote:
> > >>
> > >> Hey Paul,
> > >>> Welcome to Cordova! I've looked at your changes on github and have
> > some
> > >>> early feedback.
> > >>>
> > >>> 1) As per spec you return a Promise on battery.js but to my
> knowledge
> > we
> > >>> don't have a fallback for ES6 Promises on platforms that don't
> > support it
> > >>> yet. I would like to know what other committers think about this
> > problem.
> > >>> 2) I think the old API and the new API can co-exist for a while
> > before we
> > >>> deprecate and remove the old one. I see that the new spec uses a
> > different
> > >>> method name so we should be fine here.
> > >>>
> > >>> Thanks,
> > >>> Murat
> > >>>
> > >>> -----Original Message-----
> > >>> From: Paul Contat [mailto:contat.paul@gmail.com]
> > >>> Sent: Wednesday, July 1, 2015 12:38 AM
> > >>> To: dev@cordova.apache.org
> > >>> Subject: Introduction
> > >>>
> > >>> Hello everyone,
> > >>>
> > >>> My name is Paul Contat, and I'm an engineering student and
currently
> > doing
> > >>> an internship at W3C focusing on aligning cordova API with W3C ones
> > where
> > >>> applicable, as part of the HTML5Apps EU project (
> > >>>
> >
>
http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
> > >>> )
> > >>>
> > >>> For my internship, I’m planning to contribute to the cordova
> project,
> > >>> starting by the BatteryStatus API (
> > >>> https://issues.apache.org/jira/browse/CB-6065) if it’s possible.
> > >>>
> > >>> I've just signed the ICLA, created an account on Apache JIRA so I’m
> > ready
> > >>> to start and submitted my first pull request:
> > >>> https://github.com/apache/cordova-plugin-battery-status/pull/24
> > >>>
> > >>> I’m looking forward to feedback on whether I’m on the right path
for
> > >>> updating the Battery plugin API; I’m in particular interested to
> > understand
> > >>> if and how the current API should be deprecated once we get to a
> stage
> > >>> where the new API is deemed in a good enough shape.
> > >>>
> > >>> Best regards,
> > >>> Paul
> > >>
> > >>
> > >>
> > > --
> > > Tyler Freeman
> > > CTO, Tappur
> > > http://tappur.co
> > >
> > > Sent from mobile
> > >
> >
>
Re: Introduction
Posted by Carlos Santana <cs...@gmail.com>.
agree with Jesse battery APIs is not the best plugin to invest energy on
it, see what I did there ;-)
to answer the question on plugin dependencies, you can declare a plugin
dependency in plugin.xml
meaning that you can have in theory, a plugin cordova-plugin-promises that
is common across multiple plugins that it's only purpose is provide a
common API for other plugins.
not 100% sure, if today we check before final merge or clobber on the
resulted export module, but we can enhance it by checking the result if
it's something null, then it allows at runtime to check if the webview
provides the APIs, and if it does then it returns null, then in cordova.js
we check this and do not anything if null.
Agree with Brian, that promises are user space playland not in cordova,
webviews will eventually have them sooner than later
On Wed, Jul 8, 2015 at 12:10 PM Paul Contat <co...@gmail.com> wrote:
> Thanks for the feedback!
>
> Maybe I could determine in the cordova plugin if there is a browser
> implementation with “getOriginalSymbol(window, 'navigator.battery');” and
> return the browser object from navigator.getBattery or return the cordova
> implementation. I’ll be working on a patch toward that and will update the
> pull request accordingly.
>
> About Promise polyfill, is there any preference between a dependency on a
> npm module in package.json like “jakes es6” and a dependency on another
> Cordova plugin through plugin.xml ?
>
> Since there is no active standardization work on a contact api in W3C I
> don’t think I can usefully contribute to that. Note that the Device APIs
> Working Group is discussing its new charter, and is among other things
> discussing whether it should restart work on PIM APIs [2] — I’m happy to
> serve as a relay of feedback if this community thinks this is an area that
> would benefit from standardization.
>
> I was wondering if the implementation of notification[1] into dialogs
> plugin is interesting or should I rather work on a new plugin for screen
> orientation, for instance based on an update to [3] ?
>
> [1] http://www.w3.org/TR/notifications/
> [2] https://github.com/w3c/dap-charter/issues/2
> [3] https://github.com/gbenvenuti/cordova-plugin-screen-orientation
>
> Thanks,
> Paul
> Le mar. 7 juil. 2015 à 23:00, Nikhil Khandelwal <ni...@microsoft.com> a
> écrit :
>
> > Coming back to Joe's point of if the browser has the API, then the plugin
> > should not implement it. Is there a way for a plugin to not clobber the
> > namespace if the browser already implements it? This would be a nice way
> to
> > support Android 5+ with the browser implementation and the older version
> > with a custom Cordova implementation - considering they have the *same*
> > behavior.
> >
> > +1 to having a promise polyfill implementation in a shared plugin.
> >
> > Also, there is the orientation spec - which would be great to implement
> in
> > Cordova: http://www.w3.org/TR/screen-orientation/
> >
> > Thanks,
> > Nikhil
> >
> >
> > -----Original Message-----
> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf
> Of
> > Brian LeRoux
> > Sent: Tuesday, July 7, 2015 1:20 PM
> > To: dev@cordova.apache.org
> > Cc: Tyler Freeman
> > Subject: Re: Introduction
> >
> > Yes, lets not bikeshed block and tackle for things that are very solved
> > (async) even if the aesthetics are not to everyone's taste or on trend.
> >
> > Contacts API is heavily broken, used and needed. Its a great suggestion
> > for something that would be high impact and actually important to
> userland.
> >
> > On Tue, Jul 7, 2015 at 1:06 PM, Steven Gill <st...@gmail.com>
> > wrote:
> >
> > > If someone wants to take a stab at coming up with a proposal, go for
> it.
> > > Sounds like we need to have more discussion on what that should look
> > like.
> > >
> > > I like Jesse's suggestions of looking for browser implementations
> first.
> > >
> > > You could look into adding a promise polyfill as a cordova plugins and
> > > have it as a dependency. I found [1] after a quick google search.
> > >
> > > [1] https://github.com/vstirbu/PromisesPlugin/
> > >
> > > On Tue, Jul 7, 2015 at 12:01 PM, julio cesar sanchez <
> > > jcesarmobile@gmail.com
> > > > wrote:
> > >
> > > > It's only supported by android 5 webview (12% share right now), so I
> > > think
> > > > the plugin makes sense for now even if it's going to be deprecated
> > > > in the future and replaced by the browser battery status when more
> > > > people have android 5 or greater
> > > >
> > > > But the discussion about this should be better on the
> > > > cordova-discuss https://github.com/cordova/cordova-discuss/issues
> > > >
> > > >
> > > >
> > > > 2015-07-07 20:42 GMT+02:00 Joe Bowser <bo...@gmail.com>:
> > > >
> > > > > I hate to dash your hopes, but I think that we should probably not
> > > have a
> > > > > Battery Status plugin and defer to browser behaviour on Android,
> > > > > since Battery Status is supported on the browser with the latest
> > > > > Android WebViews, and with Crosswalk. Any plugin should just be
> > > > > glue code for facilitating this behaviour, similar to how we
> > > > > deprecated the
> > > Geolocation
> > > > > plugin on Android in favour to Browser Geolocation.
> > > > >
> > > > > That's my two cents on the issue right now.
> > > > >
> > > > > On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote:
> > > > >
> > > > > > exactly so and by all means please feel free to use that,
> > > > > > bluebird,
> > > > rsvp,
> > > > > > q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
> > > > > >
> > > > > > though I suggest one limits the scope to the other 200+
> > > > > > libraries
> > > > > claiming
> > > > > > A+ support! [2]
> > > > > >
> > > > > > ;P
> > > > > >
> > > > > > [1] https://www.npmjs.com/search?q=Promise
> > > > > > [2] https://www.npmjs.com/search?q=Promise+A%2B
> > > > > >
> > > > > >
> > > > > > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co>
> > > > wrote:
> > > > > >
> > > > > > > I'd just like to mention that jQuery has promises built-in as
> > > > > > > the $.Deferred object. It's not quite the same as the official
> > > > > > > Promises
> > > > > spec,
> > > > > > > but can be used similarly in most cases.
> > > > > > >
> > > > > > >
> > > > > > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io>
> wrote:
> > > > > > >>
> > > > > > >> We experimented with Promise polyfills and had nothing but
> > > trouble.
> > > > > I'd
> > > > > > >> like to preface by saying: lets not get into a theory war.
> > > > > > >> Some
> > > > people
> > > > > > like
> > > > > > >> promises (fine) and some do not (also fine). My stance is
> > > > > > >> that we
> > > > > should
> > > > > > >> leave that choice up to our end users.
> > > > > > >>
> > > > > > >> Lets throw some facts out to colour things.
> > > > > > >>
> > > > > > >> 1. Promises are a spec that will land in browsers natively
> > > > > > >> [1] 2. Promises as a concept have MANY polyfill
> > > > > > >> implementations 3. The polyfill landscape is largely
> > > > > > >> divergent and implement
> > > > different
> > > > > > >> flavors of the concept
> > > > > > >>
> > > > > > >> Since we implement a User Agent we *could* polyfill to spec.
> > > > > > >> As a
> > > > > > plugin.
> > > > > > >> (Jake's is probably best [2]) I'd be in favor of this and
> > > > > > >> making
> > > > that
> > > > > > THE
> > > > > > >> plugin dep for companion plugins that require Promises. The
> > > problem
> > > > > with
> > > > > > >> this is #3. If we have a window.Promise it could be clobbered
> > > > > > >> by a
> > > > > user
> > > > > > >> that is not super aware of how things are composed under the
> > hood.
> > > > If
> > > > > it
> > > > > > >> *could* happen guess what: it will. Some frameworks even
> > > > > > >> force the
> > > > > idea
> > > > > > of
> > > > > > >> Promises that may not be totally on spec. Older jQuery and
> > > > > > >> Ember
> > > > come
> > > > > to
> > > > > > >> mind.
> > > > > > >>
> > > > > > >> The other way to solve this problem is patience. This is the
> > > > > > >> path
> > > I
> > > > am
> > > > > > most
> > > > > > >> in favor of. Lets wait out the native implementation to land
> > > > > > >> in
> > > the
> > > > > > various
> > > > > > >> webviews and at such time we can start using those.
> > > > > > >>
> > > > > > >> Plugins really should wrap device and operating system API's
> > > > > > >> (in
> > > my
> > > > > > >> opinion) and we should leave library code for the user land
> > > > > > >> to
> > > > figure
> > > > > > out.
> > > > > > >> The Promise API *is a library* until such time as it has been
> > > > > > implemented
> > > > > > >> into the language runtimes natively (and not just
> > > > > > >> speculatively standardized). Ok I guess faltered into the
> > theory war part there.
> > > > ;)
> > > > > > >>
> > > > > > >> [1] https://promisesaplus.com/ [2]
> > > > > > >> https://github.com/jakearchibald/es6-promise
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <
> > > muratsu@microsoft.com
> > > > >
> > > > > > wrote:
> > > > > > >>
> > > > > > >> Hey Paul,
> > > > > > >>> Welcome to Cordova! I've looked at your changes on github
> > > > > > >>> and
> > > have
> > > > > > some
> > > > > > >>> early feedback.
> > > > > > >>>
> > > > > > >>> 1) As per spec you return a Promise on battery.js but to my
> > > > > knowledge
> > > > > > we
> > > > > > >>> don't have a fallback for ES6 Promises on platforms that
> > > > > > >>> don't
> > > > > > support it
> > > > > > >>> yet. I would like to know what other committers think about
> > > > > > >>> this
> > > > > > problem.
> > > > > > >>> 2) I think the old API and the new API can co-exist for a
> > > > > > >>> while
> > > > > > before we
> > > > > > >>> deprecate and remove the old one. I see that the new spec
> > > > > > >>> uses a
> > > > > > different
> > > > > > >>> method name so we should be fine here.
> > > > > > >>>
> > > > > > >>> Thanks,
> > > > > > >>> Murat
> > > > > > >>>
> > > > > > >>> -----Original Message-----
> > > > > > >>> From: Paul Contat [mailto:contat.paul@gmail.com]
> > > > > > >>> Sent: Wednesday, July 1, 2015 12:38 AM
> > > > > > >>> To: dev@cordova.apache.org
> > > > > > >>> Subject: Introduction
> > > > > > >>>
> > > > > > >>> Hello everyone,
> > > > > > >>>
> > > > > > >>> My name is Paul Contat, and I'm an engineering student and
> > > > currently
> > > > > > doing
> > > > > > >>> an internship at W3C focusing on aligning cordova API with
> > > > > > >>> W3C
> > > > ones
> > > > > > where
> > > > > > >>> applicable, as part of the HTML5Apps EU project (
> > > > > > >>>
> > > > > >
> > > > >
> > > >
> > > http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device
> > > -apis/
> > > > > > >>> )
> > > > > > >>>
> > > > > > >>> For my internship, I’m planning to contribute to the
> > > > > > >>> cordova
> > > > > project,
> > > > > > >>> starting by the BatteryStatus API (
> > > > > > >>> https://issues.apache.org/jira/browse/CB-6065) if it’s
> > > possible.
> > > > > > >>>
> > > > > > >>> I've just signed the ICLA, created an account on Apache
> > > > > > >>> JIRA so
> > > > I’m
> > > > > > ready
> > > > > > >>> to start and submitted my first pull request:
> > > > > > >>>
> > > > > > >>> https://github.com/apache/cordova-plugin-battery-status/pull
> > > > > > >>> /24
> > > > > > >>>
> > > > > > >>> I’m looking forward to feedback on whether I’m on the right
> > > > > > >>> path
> > > > for
> > > > > > >>> updating the Battery plugin API; I’m in particular
> > > > > > >>> interested to
> > > > > > understand
> > > > > > >>> if and how the current API should be deprecated once we get
> > > > > > >>> to a
> > > > > stage
> > > > > > >>> where the new API is deemed in a good enough shape.
> > > > > > >>>
> > > > > > >>> Best regards,
> > > > > > >>> Paul
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > > --
> > > > > > > Tyler Freeman
> > > > > > > CTO, Tappur
> > > > > > > http://tappur.co
> > > > > > >
> > > > > > > Sent from mobile
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
Re: Introduction
Posted by Paul Contat <co...@gmail.com>.
Thanks for the feedback!
Maybe I could determine in the cordova plugin if there is a browser
implementation with “getOriginalSymbol(window, 'navigator.battery');” and
return the browser object from navigator.getBattery or return the cordova
implementation. I’ll be working on a patch toward that and will update the
pull request accordingly.
About Promise polyfill, is there any preference between a dependency on a
npm module in package.json like “jakes es6” and a dependency on another
Cordova plugin through plugin.xml ?
Since there is no active standardization work on a contact api in W3C I
don’t think I can usefully contribute to that. Note that the Device APIs
Working Group is discussing its new charter, and is among other things
discussing whether it should restart work on PIM APIs [2] — I’m happy to
serve as a relay of feedback if this community thinks this is an area that
would benefit from standardization.
I was wondering if the implementation of notification[1] into dialogs
plugin is interesting or should I rather work on a new plugin for screen
orientation, for instance based on an update to [3] ?
[1] http://www.w3.org/TR/notifications/
[2] https://github.com/w3c/dap-charter/issues/2
[3] https://github.com/gbenvenuti/cordova-plugin-screen-orientation
Thanks,
Paul
Le mar. 7 juil. 2015 à 23:00, Nikhil Khandelwal <ni...@microsoft.com> a
écrit :
> Coming back to Joe's point of if the browser has the API, then the plugin
> should not implement it. Is there a way for a plugin to not clobber the
> namespace if the browser already implements it? This would be a nice way to
> support Android 5+ with the browser implementation and the older version
> with a custom Cordova implementation - considering they have the *same*
> behavior.
>
> +1 to having a promise polyfill implementation in a shared plugin.
>
> Also, there is the orientation spec - which would be great to implement in
> Cordova: http://www.w3.org/TR/screen-orientation/
>
> Thanks,
> Nikhil
>
>
> -----Original Message-----
> From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of
> Brian LeRoux
> Sent: Tuesday, July 7, 2015 1:20 PM
> To: dev@cordova.apache.org
> Cc: Tyler Freeman
> Subject: Re: Introduction
>
> Yes, lets not bikeshed block and tackle for things that are very solved
> (async) even if the aesthetics are not to everyone's taste or on trend.
>
> Contacts API is heavily broken, used and needed. Its a great suggestion
> for something that would be high impact and actually important to userland.
>
> On Tue, Jul 7, 2015 at 1:06 PM, Steven Gill <st...@gmail.com>
> wrote:
>
> > If someone wants to take a stab at coming up with a proposal, go for it.
> > Sounds like we need to have more discussion on what that should look
> like.
> >
> > I like Jesse's suggestions of looking for browser implementations first.
> >
> > You could look into adding a promise polyfill as a cordova plugins and
> > have it as a dependency. I found [1] after a quick google search.
> >
> > [1] https://github.com/vstirbu/PromisesPlugin/
> >
> > On Tue, Jul 7, 2015 at 12:01 PM, julio cesar sanchez <
> > jcesarmobile@gmail.com
> > > wrote:
> >
> > > It's only supported by android 5 webview (12% share right now), so I
> > think
> > > the plugin makes sense for now even if it's going to be deprecated
> > > in the future and replaced by the browser battery status when more
> > > people have android 5 or greater
> > >
> > > But the discussion about this should be better on the
> > > cordova-discuss https://github.com/cordova/cordova-discuss/issues
> > >
> > >
> > >
> > > 2015-07-07 20:42 GMT+02:00 Joe Bowser <bo...@gmail.com>:
> > >
> > > > I hate to dash your hopes, but I think that we should probably not
> > have a
> > > > Battery Status plugin and defer to browser behaviour on Android,
> > > > since Battery Status is supported on the browser with the latest
> > > > Android WebViews, and with Crosswalk. Any plugin should just be
> > > > glue code for facilitating this behaviour, similar to how we
> > > > deprecated the
> > Geolocation
> > > > plugin on Android in favour to Browser Geolocation.
> > > >
> > > > That's my two cents on the issue right now.
> > > >
> > > > On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote:
> > > >
> > > > > exactly so and by all means please feel free to use that,
> > > > > bluebird,
> > > rsvp,
> > > > > q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
> > > > >
> > > > > though I suggest one limits the scope to the other 200+
> > > > > libraries
> > > > claiming
> > > > > A+ support! [2]
> > > > >
> > > > > ;P
> > > > >
> > > > > [1] https://www.npmjs.com/search?q=Promise
> > > > > [2] https://www.npmjs.com/search?q=Promise+A%2B
> > > > >
> > > > >
> > > > > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co>
> > > wrote:
> > > > >
> > > > > > I'd just like to mention that jQuery has promises built-in as
> > > > > > the $.Deferred object. It's not quite the same as the official
> > > > > > Promises
> > > > spec,
> > > > > > but can be used similarly in most cases.
> > > > > >
> > > > > >
> > > > > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote:
> > > > > >>
> > > > > >> We experimented with Promise polyfills and had nothing but
> > trouble.
> > > > I'd
> > > > > >> like to preface by saying: lets not get into a theory war.
> > > > > >> Some
> > > people
> > > > > like
> > > > > >> promises (fine) and some do not (also fine). My stance is
> > > > > >> that we
> > > > should
> > > > > >> leave that choice up to our end users.
> > > > > >>
> > > > > >> Lets throw some facts out to colour things.
> > > > > >>
> > > > > >> 1. Promises are a spec that will land in browsers natively
> > > > > >> [1] 2. Promises as a concept have MANY polyfill
> > > > > >> implementations 3. The polyfill landscape is largely
> > > > > >> divergent and implement
> > > different
> > > > > >> flavors of the concept
> > > > > >>
> > > > > >> Since we implement a User Agent we *could* polyfill to spec.
> > > > > >> As a
> > > > > plugin.
> > > > > >> (Jake's is probably best [2]) I'd be in favor of this and
> > > > > >> making
> > > that
> > > > > THE
> > > > > >> plugin dep for companion plugins that require Promises. The
> > problem
> > > > with
> > > > > >> this is #3. If we have a window.Promise it could be clobbered
> > > > > >> by a
> > > > user
> > > > > >> that is not super aware of how things are composed under the
> hood.
> > > If
> > > > it
> > > > > >> *could* happen guess what: it will. Some frameworks even
> > > > > >> force the
> > > > idea
> > > > > of
> > > > > >> Promises that may not be totally on spec. Older jQuery and
> > > > > >> Ember
> > > come
> > > > to
> > > > > >> mind.
> > > > > >>
> > > > > >> The other way to solve this problem is patience. This is the
> > > > > >> path
> > I
> > > am
> > > > > most
> > > > > >> in favor of. Lets wait out the native implementation to land
> > > > > >> in
> > the
> > > > > various
> > > > > >> webviews and at such time we can start using those.
> > > > > >>
> > > > > >> Plugins really should wrap device and operating system API's
> > > > > >> (in
> > my
> > > > > >> opinion) and we should leave library code for the user land
> > > > > >> to
> > > figure
> > > > > out.
> > > > > >> The Promise API *is a library* until such time as it has been
> > > > > implemented
> > > > > >> into the language runtimes natively (and not just
> > > > > >> speculatively standardized). Ok I guess faltered into the
> theory war part there.
> > > ;)
> > > > > >>
> > > > > >> [1] https://promisesaplus.com/ [2]
> > > > > >> https://github.com/jakearchibald/es6-promise
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <
> > muratsu@microsoft.com
> > > >
> > > > > wrote:
> > > > > >>
> > > > > >> Hey Paul,
> > > > > >>> Welcome to Cordova! I've looked at your changes on github
> > > > > >>> and
> > have
> > > > > some
> > > > > >>> early feedback.
> > > > > >>>
> > > > > >>> 1) As per spec you return a Promise on battery.js but to my
> > > > knowledge
> > > > > we
> > > > > >>> don't have a fallback for ES6 Promises on platforms that
> > > > > >>> don't
> > > > > support it
> > > > > >>> yet. I would like to know what other committers think about
> > > > > >>> this
> > > > > problem.
> > > > > >>> 2) I think the old API and the new API can co-exist for a
> > > > > >>> while
> > > > > before we
> > > > > >>> deprecate and remove the old one. I see that the new spec
> > > > > >>> uses a
> > > > > different
> > > > > >>> method name so we should be fine here.
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>> Murat
> > > > > >>>
> > > > > >>> -----Original Message-----
> > > > > >>> From: Paul Contat [mailto:contat.paul@gmail.com]
> > > > > >>> Sent: Wednesday, July 1, 2015 12:38 AM
> > > > > >>> To: dev@cordova.apache.org
> > > > > >>> Subject: Introduction
> > > > > >>>
> > > > > >>> Hello everyone,
> > > > > >>>
> > > > > >>> My name is Paul Contat, and I'm an engineering student and
> > > currently
> > > > > doing
> > > > > >>> an internship at W3C focusing on aligning cordova API with
> > > > > >>> W3C
> > > ones
> > > > > where
> > > > > >>> applicable, as part of the HTML5Apps EU project (
> > > > > >>>
> > > > >
> > > >
> > >
> > http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device
> > -apis/
> > > > > >>> )
> > > > > >>>
> > > > > >>> For my internship, I’m planning to contribute to the
> > > > > >>> cordova
> > > > project,
> > > > > >>> starting by the BatteryStatus API (
> > > > > >>> https://issues.apache.org/jira/browse/CB-6065) if it’s
> > possible.
> > > > > >>>
> > > > > >>> I've just signed the ICLA, created an account on Apache
> > > > > >>> JIRA so
> > > I’m
> > > > > ready
> > > > > >>> to start and submitted my first pull request:
> > > > > >>>
> > > > > >>> https://github.com/apache/cordova-plugin-battery-status/pull
> > > > > >>> /24
> > > > > >>>
> > > > > >>> I’m looking forward to feedback on whether I’m on the right
> > > > > >>> path
> > > for
> > > > > >>> updating the Battery plugin API; I’m in particular
> > > > > >>> interested to
> > > > > understand
> > > > > >>> if and how the current API should be deprecated once we get
> > > > > >>> to a
> > > > stage
> > > > > >>> where the new API is deemed in a good enough shape.
> > > > > >>>
> > > > > >>> Best regards,
> > > > > >>> Paul
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > > --
> > > > > > Tyler Freeman
> > > > > > CTO, Tappur
> > > > > > http://tappur.co
> > > > > >
> > > > > > Sent from mobile
> > > > > >
> > > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
RE: Introduction
Posted by Nikhil Khandelwal <ni...@microsoft.com>.
Coming back to Joe's point of if the browser has the API, then the plugin should not implement it. Is there a way for a plugin to not clobber the namespace if the browser already implements it? This would be a nice way to support Android 5+ with the browser implementation and the older version with a custom Cordova implementation - considering they have the *same* behavior.
+1 to having a promise polyfill implementation in a shared plugin.
Also, there is the orientation spec - which would be great to implement in Cordova: http://www.w3.org/TR/screen-orientation/
Thanks,
Nikhil
-----Original Message-----
From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of Brian LeRoux
Sent: Tuesday, July 7, 2015 1:20 PM
To: dev@cordova.apache.org
Cc: Tyler Freeman
Subject: Re: Introduction
Yes, lets not bikeshed block and tackle for things that are very solved
(async) even if the aesthetics are not to everyone's taste or on trend.
Contacts API is heavily broken, used and needed. Its a great suggestion for something that would be high impact and actually important to userland.
On Tue, Jul 7, 2015 at 1:06 PM, Steven Gill <st...@gmail.com> wrote:
> If someone wants to take a stab at coming up with a proposal, go for it.
> Sounds like we need to have more discussion on what that should look like.
>
> I like Jesse's suggestions of looking for browser implementations first.
>
> You could look into adding a promise polyfill as a cordova plugins and
> have it as a dependency. I found [1] after a quick google search.
>
> [1] https://github.com/vstirbu/PromisesPlugin/
>
> On Tue, Jul 7, 2015 at 12:01 PM, julio cesar sanchez <
> jcesarmobile@gmail.com
> > wrote:
>
> > It's only supported by android 5 webview (12% share right now), so I
> think
> > the plugin makes sense for now even if it's going to be deprecated
> > in the future and replaced by the browser battery status when more
> > people have android 5 or greater
> >
> > But the discussion about this should be better on the
> > cordova-discuss https://github.com/cordova/cordova-discuss/issues
> >
> >
> >
> > 2015-07-07 20:42 GMT+02:00 Joe Bowser <bo...@gmail.com>:
> >
> > > I hate to dash your hopes, but I think that we should probably not
> have a
> > > Battery Status plugin and defer to browser behaviour on Android,
> > > since Battery Status is supported on the browser with the latest
> > > Android WebViews, and with Crosswalk. Any plugin should just be
> > > glue code for facilitating this behaviour, similar to how we
> > > deprecated the
> Geolocation
> > > plugin on Android in favour to Browser Geolocation.
> > >
> > > That's my two cents on the issue right now.
> > >
> > > On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > exactly so and by all means please feel free to use that,
> > > > bluebird,
> > rsvp,
> > > > q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
> > > >
> > > > though I suggest one limits the scope to the other 200+
> > > > libraries
> > > claiming
> > > > A+ support! [2]
> > > >
> > > > ;P
> > > >
> > > > [1] https://www.npmjs.com/search?q=Promise
> > > > [2] https://www.npmjs.com/search?q=Promise+A%2B
> > > >
> > > >
> > > > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co>
> > wrote:
> > > >
> > > > > I'd just like to mention that jQuery has promises built-in as
> > > > > the $.Deferred object. It's not quite the same as the official
> > > > > Promises
> > > spec,
> > > > > but can be used similarly in most cases.
> > > > >
> > > > >
> > > > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote:
> > > > >>
> > > > >> We experimented with Promise polyfills and had nothing but
> trouble.
> > > I'd
> > > > >> like to preface by saying: lets not get into a theory war.
> > > > >> Some
> > people
> > > > like
> > > > >> promises (fine) and some do not (also fine). My stance is
> > > > >> that we
> > > should
> > > > >> leave that choice up to our end users.
> > > > >>
> > > > >> Lets throw some facts out to colour things.
> > > > >>
> > > > >> 1. Promises are a spec that will land in browsers natively
> > > > >> [1] 2. Promises as a concept have MANY polyfill
> > > > >> implementations 3. The polyfill landscape is largely
> > > > >> divergent and implement
> > different
> > > > >> flavors of the concept
> > > > >>
> > > > >> Since we implement a User Agent we *could* polyfill to spec.
> > > > >> As a
> > > > plugin.
> > > > >> (Jake's is probably best [2]) I'd be in favor of this and
> > > > >> making
> > that
> > > > THE
> > > > >> plugin dep for companion plugins that require Promises. The
> problem
> > > with
> > > > >> this is #3. If we have a window.Promise it could be clobbered
> > > > >> by a
> > > user
> > > > >> that is not super aware of how things are composed under the hood.
> > If
> > > it
> > > > >> *could* happen guess what: it will. Some frameworks even
> > > > >> force the
> > > idea
> > > > of
> > > > >> Promises that may not be totally on spec. Older jQuery and
> > > > >> Ember
> > come
> > > to
> > > > >> mind.
> > > > >>
> > > > >> The other way to solve this problem is patience. This is the
> > > > >> path
> I
> > am
> > > > most
> > > > >> in favor of. Lets wait out the native implementation to land
> > > > >> in
> the
> > > > various
> > > > >> webviews and at such time we can start using those.
> > > > >>
> > > > >> Plugins really should wrap device and operating system API's
> > > > >> (in
> my
> > > > >> opinion) and we should leave library code for the user land
> > > > >> to
> > figure
> > > > out.
> > > > >> The Promise API *is a library* until such time as it has been
> > > > implemented
> > > > >> into the language runtimes natively (and not just
> > > > >> speculatively standardized). Ok I guess faltered into the theory war part there.
> > ;)
> > > > >>
> > > > >> [1] https://promisesaplus.com/ [2]
> > > > >> https://github.com/jakearchibald/es6-promise
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <
> muratsu@microsoft.com
> > >
> > > > wrote:
> > > > >>
> > > > >> Hey Paul,
> > > > >>> Welcome to Cordova! I've looked at your changes on github
> > > > >>> and
> have
> > > > some
> > > > >>> early feedback.
> > > > >>>
> > > > >>> 1) As per spec you return a Promise on battery.js but to my
> > > knowledge
> > > > we
> > > > >>> don't have a fallback for ES6 Promises on platforms that
> > > > >>> don't
> > > > support it
> > > > >>> yet. I would like to know what other committers think about
> > > > >>> this
> > > > problem.
> > > > >>> 2) I think the old API and the new API can co-exist for a
> > > > >>> while
> > > > before we
> > > > >>> deprecate and remove the old one. I see that the new spec
> > > > >>> uses a
> > > > different
> > > > >>> method name so we should be fine here.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Murat
> > > > >>>
> > > > >>> -----Original Message-----
> > > > >>> From: Paul Contat [mailto:contat.paul@gmail.com]
> > > > >>> Sent: Wednesday, July 1, 2015 12:38 AM
> > > > >>> To: dev@cordova.apache.org
> > > > >>> Subject: Introduction
> > > > >>>
> > > > >>> Hello everyone,
> > > > >>>
> > > > >>> My name is Paul Contat, and I'm an engineering student and
> > currently
> > > > doing
> > > > >>> an internship at W3C focusing on aligning cordova API with
> > > > >>> W3C
> > ones
> > > > where
> > > > >>> applicable, as part of the HTML5Apps EU project (
> > > > >>>
> > > >
> > >
> >
> http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device
> -apis/
> > > > >>> )
> > > > >>>
> > > > >>> For my internship, I’m planning to contribute to the
> > > > >>> cordova
> > > project,
> > > > >>> starting by the BatteryStatus API (
> > > > >>> https://issues.apache.org/jira/browse/CB-6065) if it’s
> possible.
> > > > >>>
> > > > >>> I've just signed the ICLA, created an account on Apache
> > > > >>> JIRA so
> > I’m
> > > > ready
> > > > >>> to start and submitted my first pull request:
> > > > >>>
> > > > >>> https://github.com/apache/cordova-plugin-battery-status/pull
> > > > >>> /24
> > > > >>>
> > > > >>> I’m looking forward to feedback on whether I’m on the right
> > > > >>> path
> > for
> > > > >>> updating the Battery plugin API; I’m in particular
> > > > >>> interested to
> > > > understand
> > > > >>> if and how the current API should be deprecated once we get
> > > > >>> to a
> > > stage
> > > > >>> where the new API is deemed in a good enough shape.
> > > > >>>
> > > > >>> Best regards,
> > > > >>> Paul
> > > > >>
> > > > >>
> > > > >>
> > > > > --
> > > > > Tyler Freeman
> > > > > CTO, Tappur
> > > > > http://tappur.co
> > > > >
> > > > > Sent from mobile
> > > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Introduction
Posted by Brian LeRoux <b...@brian.io>.
Yes, lets not bikeshed block and tackle for things that are very solved
(async) even if the aesthetics are not to everyone's taste or on trend.
Contacts API is heavily broken, used and needed. Its a great suggestion for
something that would be high impact and actually important to userland.
On Tue, Jul 7, 2015 at 1:06 PM, Steven Gill <st...@gmail.com> wrote:
> If someone wants to take a stab at coming up with a proposal, go for it.
> Sounds like we need to have more discussion on what that should look like.
>
> I like Jesse's suggestions of looking for browser implementations first.
>
> You could look into adding a promise polyfill as a cordova plugins and have
> it as a dependency. I found [1] after a quick google search.
>
> [1] https://github.com/vstirbu/PromisesPlugin/
>
> On Tue, Jul 7, 2015 at 12:01 PM, julio cesar sanchez <
> jcesarmobile@gmail.com
> > wrote:
>
> > It's only supported by android 5 webview (12% share right now), so I
> think
> > the plugin makes sense for now even if it's going to be deprecated in the
> > future and replaced by the browser battery status when more people have
> > android 5 or greater
> >
> > But the discussion about this should be better on the cordova-discuss
> > https://github.com/cordova/cordova-discuss/issues
> >
> >
> >
> > 2015-07-07 20:42 GMT+02:00 Joe Bowser <bo...@gmail.com>:
> >
> > > I hate to dash your hopes, but I think that we should probably not
> have a
> > > Battery Status plugin and defer to browser behaviour on Android, since
> > > Battery Status is supported on the browser with the latest Android
> > > WebViews, and with Crosswalk. Any plugin should just be glue code for
> > > facilitating this behaviour, similar to how we deprecated the
> Geolocation
> > > plugin on Android in favour to Browser Geolocation.
> > >
> > > That's my two cents on the issue right now.
> > >
> > > On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > exactly so and by all means please feel free to use that, bluebird,
> > rsvp,
> > > > q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
> > > >
> > > > though I suggest one limits the scope to the other 200+ libraries
> > > claiming
> > > > A+ support! [2]
> > > >
> > > > ;P
> > > >
> > > > [1] https://www.npmjs.com/search?q=Promise
> > > > [2] https://www.npmjs.com/search?q=Promise+A%2B
> > > >
> > > >
> > > > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co>
> > wrote:
> > > >
> > > > > I'd just like to mention that jQuery has promises built-in as the
> > > > > $.Deferred object. It's not quite the same as the official Promises
> > > spec,
> > > > > but can be used similarly in most cases.
> > > > >
> > > > >
> > > > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote:
> > > > >>
> > > > >> We experimented with Promise polyfills and had nothing but
> trouble.
> > > I'd
> > > > >> like to preface by saying: lets not get into a theory war. Some
> > people
> > > > like
> > > > >> promises (fine) and some do not (also fine). My stance is that we
> > > should
> > > > >> leave that choice up to our end users.
> > > > >>
> > > > >> Lets throw some facts out to colour things.
> > > > >>
> > > > >> 1. Promises are a spec that will land in browsers natively [1]
> > > > >> 2. Promises as a concept have MANY polyfill implementations
> > > > >> 3. The polyfill landscape is largely divergent and implement
> > different
> > > > >> flavors of the concept
> > > > >>
> > > > >> Since we implement a User Agent we *could* polyfill to spec. As a
> > > > plugin.
> > > > >> (Jake's is probably best [2]) I'd be in favor of this and making
> > that
> > > > THE
> > > > >> plugin dep for companion plugins that require Promises. The
> problem
> > > with
> > > > >> this is #3. If we have a window.Promise it could be clobbered by a
> > > user
> > > > >> that is not super aware of how things are composed under the hood.
> > If
> > > it
> > > > >> *could* happen guess what: it will. Some frameworks even force the
> > > idea
> > > > of
> > > > >> Promises that may not be totally on spec. Older jQuery and Ember
> > come
> > > to
> > > > >> mind.
> > > > >>
> > > > >> The other way to solve this problem is patience. This is the path
> I
> > am
> > > > most
> > > > >> in favor of. Lets wait out the native implementation to land in
> the
> > > > various
> > > > >> webviews and at such time we can start using those.
> > > > >>
> > > > >> Plugins really should wrap device and operating system API's (in
> my
> > > > >> opinion) and we should leave library code for the user land to
> > figure
> > > > out.
> > > > >> The Promise API *is a library* until such time as it has been
> > > > implemented
> > > > >> into the language runtimes natively (and not just speculatively
> > > > >> standardized). Ok I guess faltered into the theory war part there.
> > ;)
> > > > >>
> > > > >> [1] https://promisesaplus.com/
> > > > >> [2] https://github.com/jakearchibald/es6-promise
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <
> muratsu@microsoft.com
> > >
> > > > wrote:
> > > > >>
> > > > >> Hey Paul,
> > > > >>> Welcome to Cordova! I've looked at your changes on github and
> have
> > > > some
> > > > >>> early feedback.
> > > > >>>
> > > > >>> 1) As per spec you return a Promise on battery.js but to my
> > > knowledge
> > > > we
> > > > >>> don't have a fallback for ES6 Promises on platforms that don't
> > > > support it
> > > > >>> yet. I would like to know what other committers think about this
> > > > problem.
> > > > >>> 2) I think the old API and the new API can co-exist for a while
> > > > before we
> > > > >>> deprecate and remove the old one. I see that the new spec uses a
> > > > different
> > > > >>> method name so we should be fine here.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Murat
> > > > >>>
> > > > >>> -----Original Message-----
> > > > >>> From: Paul Contat [mailto:contat.paul@gmail.com]
> > > > >>> Sent: Wednesday, July 1, 2015 12:38 AM
> > > > >>> To: dev@cordova.apache.org
> > > > >>> Subject: Introduction
> > > > >>>
> > > > >>> Hello everyone,
> > > > >>>
> > > > >>> My name is Paul Contat, and I'm an engineering student and
> > currently
> > > > doing
> > > > >>> an internship at W3C focusing on aligning cordova API with W3C
> > ones
> > > > where
> > > > >>> applicable, as part of the HTML5Apps EU project (
> > > > >>>
> > > >
> > >
> >
> http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
> > > > >>> )
> > > > >>>
> > > > >>> For my internship, I’m planning to contribute to the cordova
> > > project,
> > > > >>> starting by the BatteryStatus API (
> > > > >>> https://issues.apache.org/jira/browse/CB-6065) if it’s
> possible.
> > > > >>>
> > > > >>> I've just signed the ICLA, created an account on Apache JIRA so
> > I’m
> > > > ready
> > > > >>> to start and submitted my first pull request:
> > > > >>> https://github.com/apache/cordova-plugin-battery-status/pull/24
> > > > >>>
> > > > >>> I’m looking forward to feedback on whether I’m on the right path
> > for
> > > > >>> updating the Battery plugin API; I’m in particular interested to
> > > > understand
> > > > >>> if and how the current API should be deprecated once we get to a
> > > stage
> > > > >>> where the new API is deemed in a good enough shape.
> > > > >>>
> > > > >>> Best regards,
> > > > >>> Paul
> > > > >>
> > > > >>
> > > > >>
> > > > > --
> > > > > Tyler Freeman
> > > > > CTO, Tappur
> > > > > http://tappur.co
> > > > >
> > > > > Sent from mobile
> > > > >
> > > >
> > >
> >
>
Re: Introduction
Posted by Steven Gill <st...@gmail.com>.
If someone wants to take a stab at coming up with a proposal, go for it.
Sounds like we need to have more discussion on what that should look like.
I like Jesse's suggestions of looking for browser implementations first.
You could look into adding a promise polyfill as a cordova plugins and have
it as a dependency. I found [1] after a quick google search.
[1] https://github.com/vstirbu/PromisesPlugin/
On Tue, Jul 7, 2015 at 12:01 PM, julio cesar sanchez <jcesarmobile@gmail.com
> wrote:
> It's only supported by android 5 webview (12% share right now), so I think
> the plugin makes sense for now even if it's going to be deprecated in the
> future and replaced by the browser battery status when more people have
> android 5 or greater
>
> But the discussion about this should be better on the cordova-discuss
> https://github.com/cordova/cordova-discuss/issues
>
>
>
> 2015-07-07 20:42 GMT+02:00 Joe Bowser <bo...@gmail.com>:
>
> > I hate to dash your hopes, but I think that we should probably not have a
> > Battery Status plugin and defer to browser behaviour on Android, since
> > Battery Status is supported on the browser with the latest Android
> > WebViews, and with Crosswalk. Any plugin should just be glue code for
> > facilitating this behaviour, similar to how we deprecated the Geolocation
> > plugin on Android in favour to Browser Geolocation.
> >
> > That's my two cents on the issue right now.
> >
> > On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote:
> >
> > > exactly so and by all means please feel free to use that, bluebird,
> rsvp,
> > > q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
> > >
> > > though I suggest one limits the scope to the other 200+ libraries
> > claiming
> > > A+ support! [2]
> > >
> > > ;P
> > >
> > > [1] https://www.npmjs.com/search?q=Promise
> > > [2] https://www.npmjs.com/search?q=Promise+A%2B
> > >
> > >
> > > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co>
> wrote:
> > >
> > > > I'd just like to mention that jQuery has promises built-in as the
> > > > $.Deferred object. It's not quite the same as the official Promises
> > spec,
> > > > but can be used similarly in most cases.
> > > >
> > > >
> > > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote:
> > > >>
> > > >> We experimented with Promise polyfills and had nothing but trouble.
> > I'd
> > > >> like to preface by saying: lets not get into a theory war. Some
> people
> > > like
> > > >> promises (fine) and some do not (also fine). My stance is that we
> > should
> > > >> leave that choice up to our end users.
> > > >>
> > > >> Lets throw some facts out to colour things.
> > > >>
> > > >> 1. Promises are a spec that will land in browsers natively [1]
> > > >> 2. Promises as a concept have MANY polyfill implementations
> > > >> 3. The polyfill landscape is largely divergent and implement
> different
> > > >> flavors of the concept
> > > >>
> > > >> Since we implement a User Agent we *could* polyfill to spec. As a
> > > plugin.
> > > >> (Jake's is probably best [2]) I'd be in favor of this and making
> that
> > > THE
> > > >> plugin dep for companion plugins that require Promises. The problem
> > with
> > > >> this is #3. If we have a window.Promise it could be clobbered by a
> > user
> > > >> that is not super aware of how things are composed under the hood.
> If
> > it
> > > >> *could* happen guess what: it will. Some frameworks even force the
> > idea
> > > of
> > > >> Promises that may not be totally on spec. Older jQuery and Ember
> come
> > to
> > > >> mind.
> > > >>
> > > >> The other way to solve this problem is patience. This is the path I
> am
> > > most
> > > >> in favor of. Lets wait out the native implementation to land in the
> > > various
> > > >> webviews and at such time we can start using those.
> > > >>
> > > >> Plugins really should wrap device and operating system API's (in my
> > > >> opinion) and we should leave library code for the user land to
> figure
> > > out.
> > > >> The Promise API *is a library* until such time as it has been
> > > implemented
> > > >> into the language runtimes natively (and not just speculatively
> > > >> standardized). Ok I guess faltered into the theory war part there.
> ;)
> > > >>
> > > >> [1] https://promisesaplus.com/
> > > >> [2] https://github.com/jakearchibald/es6-promise
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <muratsu@microsoft.com
> >
> > > wrote:
> > > >>
> > > >> Hey Paul,
> > > >>> Welcome to Cordova! I've looked at your changes on github and have
> > > some
> > > >>> early feedback.
> > > >>>
> > > >>> 1) As per spec you return a Promise on battery.js but to my
> > knowledge
> > > we
> > > >>> don't have a fallback for ES6 Promises on platforms that don't
> > > support it
> > > >>> yet. I would like to know what other committers think about this
> > > problem.
> > > >>> 2) I think the old API and the new API can co-exist for a while
> > > before we
> > > >>> deprecate and remove the old one. I see that the new spec uses a
> > > different
> > > >>> method name so we should be fine here.
> > > >>>
> > > >>> Thanks,
> > > >>> Murat
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: Paul Contat [mailto:contat.paul@gmail.com]
> > > >>> Sent: Wednesday, July 1, 2015 12:38 AM
> > > >>> To: dev@cordova.apache.org
> > > >>> Subject: Introduction
> > > >>>
> > > >>> Hello everyone,
> > > >>>
> > > >>> My name is Paul Contat, and I'm an engineering student and
> currently
> > > doing
> > > >>> an internship at W3C focusing on aligning cordova API with W3C
> ones
> > > where
> > > >>> applicable, as part of the HTML5Apps EU project (
> > > >>>
> > >
> >
> http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
> > > >>> )
> > > >>>
> > > >>> For my internship, I’m planning to contribute to the cordova
> > project,
> > > >>> starting by the BatteryStatus API (
> > > >>> https://issues.apache.org/jira/browse/CB-6065) if it’s possible.
> > > >>>
> > > >>> I've just signed the ICLA, created an account on Apache JIRA so
> I’m
> > > ready
> > > >>> to start and submitted my first pull request:
> > > >>> https://github.com/apache/cordova-plugin-battery-status/pull/24
> > > >>>
> > > >>> I’m looking forward to feedback on whether I’m on the right path
> for
> > > >>> updating the Battery plugin API; I’m in particular interested to
> > > understand
> > > >>> if and how the current API should be deprecated once we get to a
> > stage
> > > >>> where the new API is deemed in a good enough shape.
> > > >>>
> > > >>> Best regards,
> > > >>> Paul
> > > >>
> > > >>
> > > >>
> > > > --
> > > > Tyler Freeman
> > > > CTO, Tappur
> > > > http://tappur.co
> > > >
> > > > Sent from mobile
> > > >
> > >
> >
>
Re: Introduction
Posted by Jesse <pu...@gmail.com>.
IMHO, no-one uses this api so this would be an extremely low risk project.
Please, before providing a Promise polyfil, verify that it is not already
defined by the browser.
... and before providing the Battery api, verify that it is not already
defined by the browser.
Personally, I think if you wanted to take on a project that would get used,
the Contacts API is dangling there for the taking, and a much better
candidate.
My team is hiring!
@purplecabbage
risingj.com
On Tue, Jul 7, 2015 at 12:01 PM, julio cesar sanchez <jcesarmobile@gmail.com
> wrote:
> It's only supported by android 5 webview (12% share right now), so I think
> the plugin makes sense for now even if it's going to be deprecated in the
> future and replaced by the browser battery status when more people have
> android 5 or greater
>
> But the discussion about this should be better on the cordova-discuss
> https://github.com/cordova/cordova-discuss/issues
>
>
>
> 2015-07-07 20:42 GMT+02:00 Joe Bowser <bo...@gmail.com>:
>
> > I hate to dash your hopes, but I think that we should probably not have a
> > Battery Status plugin and defer to browser behaviour on Android, since
> > Battery Status is supported on the browser with the latest Android
> > WebViews, and with Crosswalk. Any plugin should just be glue code for
> > facilitating this behaviour, similar to how we deprecated the Geolocation
> > plugin on Android in favour to Browser Geolocation.
> >
> > That's my two cents on the issue right now.
> >
> > On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote:
> >
> > > exactly so and by all means please feel free to use that, bluebird,
> rsvp,
> > > q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
> > >
> > > though I suggest one limits the scope to the other 200+ libraries
> > claiming
> > > A+ support! [2]
> > >
> > > ;P
> > >
> > > [1] https://www.npmjs.com/search?q=Promise
> > > [2] https://www.npmjs.com/search?q=Promise+A%2B
> > >
> > >
> > > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co>
> wrote:
> > >
> > > > I'd just like to mention that jQuery has promises built-in as the
> > > > $.Deferred object. It's not quite the same as the official Promises
> > spec,
> > > > but can be used similarly in most cases.
> > > >
> > > >
> > > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote:
> > > >>
> > > >> We experimented with Promise polyfills and had nothing but trouble.
> > I'd
> > > >> like to preface by saying: lets not get into a theory war. Some
> people
> > > like
> > > >> promises (fine) and some do not (also fine). My stance is that we
> > should
> > > >> leave that choice up to our end users.
> > > >>
> > > >> Lets throw some facts out to colour things.
> > > >>
> > > >> 1. Promises are a spec that will land in browsers natively [1]
> > > >> 2. Promises as a concept have MANY polyfill implementations
> > > >> 3. The polyfill landscape is largely divergent and implement
> different
> > > >> flavors of the concept
> > > >>
> > > >> Since we implement a User Agent we *could* polyfill to spec. As a
> > > plugin.
> > > >> (Jake's is probably best [2]) I'd be in favor of this and making
> that
> > > THE
> > > >> plugin dep for companion plugins that require Promises. The problem
> > with
> > > >> this is #3. If we have a window.Promise it could be clobbered by a
> > user
> > > >> that is not super aware of how things are composed under the hood.
> If
> > it
> > > >> *could* happen guess what: it will. Some frameworks even force the
> > idea
> > > of
> > > >> Promises that may not be totally on spec. Older jQuery and Ember
> come
> > to
> > > >> mind.
> > > >>
> > > >> The other way to solve this problem is patience. This is the path I
> am
> > > most
> > > >> in favor of. Lets wait out the native implementation to land in the
> > > various
> > > >> webviews and at such time we can start using those.
> > > >>
> > > >> Plugins really should wrap device and operating system API's (in my
> > > >> opinion) and we should leave library code for the user land to
> figure
> > > out.
> > > >> The Promise API *is a library* until such time as it has been
> > > implemented
> > > >> into the language runtimes natively (and not just speculatively
> > > >> standardized). Ok I guess faltered into the theory war part there.
> ;)
> > > >>
> > > >> [1] https://promisesaplus.com/
> > > >> [2] https://github.com/jakearchibald/es6-promise
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <muratsu@microsoft.com
> >
> > > wrote:
> > > >>
> > > >> Hey Paul,
> > > >>> Welcome to Cordova! I've looked at your changes on github and have
> > > some
> > > >>> early feedback.
> > > >>>
> > > >>> 1) As per spec you return a Promise on battery.js but to my
> > knowledge
> > > we
> > > >>> don't have a fallback for ES6 Promises on platforms that don't
> > > support it
> > > >>> yet. I would like to know what other committers think about this
> > > problem.
> > > >>> 2) I think the old API and the new API can co-exist for a while
> > > before we
> > > >>> deprecate and remove the old one. I see that the new spec uses a
> > > different
> > > >>> method name so we should be fine here.
> > > >>>
> > > >>> Thanks,
> > > >>> Murat
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: Paul Contat [mailto:contat.paul@gmail.com]
> > > >>> Sent: Wednesday, July 1, 2015 12:38 AM
> > > >>> To: dev@cordova.apache.org
> > > >>> Subject: Introduction
> > > >>>
> > > >>> Hello everyone,
> > > >>>
> > > >>> My name is Paul Contat, and I'm an engineering student and
> currently
> > > doing
> > > >>> an internship at W3C focusing on aligning cordova API with W3C
> ones
> > > where
> > > >>> applicable, as part of the HTML5Apps EU project (
> > > >>>
> > >
> >
> http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
> > > >>> )
> > > >>>
> > > >>> For my internship, I’m planning to contribute to the cordova
> > project,
> > > >>> starting by the BatteryStatus API (
> > > >>> https://issues.apache.org/jira/browse/CB-6065) if it’s possible.
> > > >>>
> > > >>> I've just signed the ICLA, created an account on Apache JIRA so
> I’m
> > > ready
> > > >>> to start and submitted my first pull request:
> > > >>> https://github.com/apache/cordova-plugin-battery-status/pull/24
> > > >>>
> > > >>> I’m looking forward to feedback on whether I’m on the right path
> for
> > > >>> updating the Battery plugin API; I’m in particular interested to
> > > understand
> > > >>> if and how the current API should be deprecated once we get to a
> > stage
> > > >>> where the new API is deemed in a good enough shape.
> > > >>>
> > > >>> Best regards,
> > > >>> Paul
> > > >>
> > > >>
> > > >>
> > > > --
> > > > Tyler Freeman
> > > > CTO, Tappur
> > > > http://tappur.co
> > > >
> > > > Sent from mobile
> > > >
> > >
> >
>
Re: Introduction
Posted by julio cesar sanchez <jc...@gmail.com>.
It's only supported by android 5 webview (12% share right now), so I think
the plugin makes sense for now even if it's going to be deprecated in the
future and replaced by the browser battery status when more people have
android 5 or greater
But the discussion about this should be better on the cordova-discuss
https://github.com/cordova/cordova-discuss/issues
2015-07-07 20:42 GMT+02:00 Joe Bowser <bo...@gmail.com>:
> I hate to dash your hopes, but I think that we should probably not have a
> Battery Status plugin and defer to browser behaviour on Android, since
> Battery Status is supported on the browser with the latest Android
> WebViews, and with Crosswalk. Any plugin should just be glue code for
> facilitating this behaviour, similar to how we deprecated the Geolocation
> plugin on Android in favour to Browser Geolocation.
>
> That's my two cents on the issue right now.
>
> On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote:
>
> > exactly so and by all means please feel free to use that, bluebird, rsvp,
> > q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
> >
> > though I suggest one limits the scope to the other 200+ libraries
> claiming
> > A+ support! [2]
> >
> > ;P
> >
> > [1] https://www.npmjs.com/search?q=Promise
> > [2] https://www.npmjs.com/search?q=Promise+A%2B
> >
> >
> > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co> wrote:
> >
> > > I'd just like to mention that jQuery has promises built-in as the
> > > $.Deferred object. It's not quite the same as the official Promises
> spec,
> > > but can be used similarly in most cases.
> > >
> > >
> > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote:
> > >>
> > >> We experimented with Promise polyfills and had nothing but trouble.
> I'd
> > >> like to preface by saying: lets not get into a theory war. Some people
> > like
> > >> promises (fine) and some do not (also fine). My stance is that we
> should
> > >> leave that choice up to our end users.
> > >>
> > >> Lets throw some facts out to colour things.
> > >>
> > >> 1. Promises are a spec that will land in browsers natively [1]
> > >> 2. Promises as a concept have MANY polyfill implementations
> > >> 3. The polyfill landscape is largely divergent and implement different
> > >> flavors of the concept
> > >>
> > >> Since we implement a User Agent we *could* polyfill to spec. As a
> > plugin.
> > >> (Jake's is probably best [2]) I'd be in favor of this and making that
> > THE
> > >> plugin dep for companion plugins that require Promises. The problem
> with
> > >> this is #3. If we have a window.Promise it could be clobbered by a
> user
> > >> that is not super aware of how things are composed under the hood. If
> it
> > >> *could* happen guess what: it will. Some frameworks even force the
> idea
> > of
> > >> Promises that may not be totally on spec. Older jQuery and Ember come
> to
> > >> mind.
> > >>
> > >> The other way to solve this problem is patience. This is the path I am
> > most
> > >> in favor of. Lets wait out the native implementation to land in the
> > various
> > >> webviews and at such time we can start using those.
> > >>
> > >> Plugins really should wrap device and operating system API's (in my
> > >> opinion) and we should leave library code for the user land to figure
> > out.
> > >> The Promise API *is a library* until such time as it has been
> > implemented
> > >> into the language runtimes natively (and not just speculatively
> > >> standardized). Ok I guess faltered into the theory war part there. ;)
> > >>
> > >> [1] https://promisesaplus.com/
> > >> [2] https://github.com/jakearchibald/es6-promise
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <mu...@microsoft.com>
> > wrote:
> > >>
> > >> Hey Paul,
> > >>> Welcome to Cordova! I've looked at your changes on github and have
> > some
> > >>> early feedback.
> > >>>
> > >>> 1) As per spec you return a Promise on battery.js but to my
> knowledge
> > we
> > >>> don't have a fallback for ES6 Promises on platforms that don't
> > support it
> > >>> yet. I would like to know what other committers think about this
> > problem.
> > >>> 2) I think the old API and the new API can co-exist for a while
> > before we
> > >>> deprecate and remove the old one. I see that the new spec uses a
> > different
> > >>> method name so we should be fine here.
> > >>>
> > >>> Thanks,
> > >>> Murat
> > >>>
> > >>> -----Original Message-----
> > >>> From: Paul Contat [mailto:contat.paul@gmail.com]
> > >>> Sent: Wednesday, July 1, 2015 12:38 AM
> > >>> To: dev@cordova.apache.org
> > >>> Subject: Introduction
> > >>>
> > >>> Hello everyone,
> > >>>
> > >>> My name is Paul Contat, and I'm an engineering student and currently
> > doing
> > >>> an internship at W3C focusing on aligning cordova API with W3C ones
> > where
> > >>> applicable, as part of the HTML5Apps EU project (
> > >>>
> >
> http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
> > >>> )
> > >>>
> > >>> For my internship, I’m planning to contribute to the cordova
> project,
> > >>> starting by the BatteryStatus API (
> > >>> https://issues.apache.org/jira/browse/CB-6065) if it’s possible.
> > >>>
> > >>> I've just signed the ICLA, created an account on Apache JIRA so I’m
> > ready
> > >>> to start and submitted my first pull request:
> > >>> https://github.com/apache/cordova-plugin-battery-status/pull/24
> > >>>
> > >>> I’m looking forward to feedback on whether I’m on the right path for
> > >>> updating the Battery plugin API; I’m in particular interested to
> > understand
> > >>> if and how the current API should be deprecated once we get to a
> stage
> > >>> where the new API is deemed in a good enough shape.
> > >>>
> > >>> Best regards,
> > >>> Paul
> > >>
> > >>
> > >>
> > > --
> > > Tyler Freeman
> > > CTO, Tappur
> > > http://tappur.co
> > >
> > > Sent from mobile
> > >
> >
>
Re: Introduction
Posted by Joe Bowser <bo...@gmail.com>.
I hate to dash your hopes, but I think that we should probably not have a
Battery Status plugin and defer to browser behaviour on Android, since
Battery Status is supported on the browser with the latest Android
WebViews, and with Crosswalk. Any plugin should just be glue code for
facilitating this behaviour, similar to how we deprecated the Geolocation
plugin on Android in favour to Browser Geolocation.
That's my two cents on the issue right now.
On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote:
> exactly so and by all means please feel free to use that, bluebird, rsvp,
> q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
>
> though I suggest one limits the scope to the other 200+ libraries claiming
> A+ support! [2]
>
> ;P
>
> [1] https://www.npmjs.com/search?q=Promise
> [2] https://www.npmjs.com/search?q=Promise+A%2B
>
>
> On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co> wrote:
>
> > I'd just like to mention that jQuery has promises built-in as the
> > $.Deferred object. It's not quite the same as the official Promises spec,
> > but can be used similarly in most cases.
> >
> >
> > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote:
> >>
> >> We experimented with Promise polyfills and had nothing but trouble. I'd
> >> like to preface by saying: lets not get into a theory war. Some people
> like
> >> promises (fine) and some do not (also fine). My stance is that we should
> >> leave that choice up to our end users.
> >>
> >> Lets throw some facts out to colour things.
> >>
> >> 1. Promises are a spec that will land in browsers natively [1]
> >> 2. Promises as a concept have MANY polyfill implementations
> >> 3. The polyfill landscape is largely divergent and implement different
> >> flavors of the concept
> >>
> >> Since we implement a User Agent we *could* polyfill to spec. As a
> plugin.
> >> (Jake's is probably best [2]) I'd be in favor of this and making that
> THE
> >> plugin dep for companion plugins that require Promises. The problem with
> >> this is #3. If we have a window.Promise it could be clobbered by a user
> >> that is not super aware of how things are composed under the hood. If it
> >> *could* happen guess what: it will. Some frameworks even force the idea
> of
> >> Promises that may not be totally on spec. Older jQuery and Ember come to
> >> mind.
> >>
> >> The other way to solve this problem is patience. This is the path I am
> most
> >> in favor of. Lets wait out the native implementation to land in the
> various
> >> webviews and at such time we can start using those.
> >>
> >> Plugins really should wrap device and operating system API's (in my
> >> opinion) and we should leave library code for the user land to figure
> out.
> >> The Promise API *is a library* until such time as it has been
> implemented
> >> into the language runtimes natively (and not just speculatively
> >> standardized). Ok I guess faltered into the theory war part there. ;)
> >>
> >> [1] https://promisesaplus.com/
> >> [2] https://github.com/jakearchibald/es6-promise
> >>
> >>
> >>
> >>
> >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <mu...@microsoft.com>
> wrote:
> >>
> >> Hey Paul,
> >>> Welcome to Cordova! I've looked at your changes on github and have
> some
> >>> early feedback.
> >>>
> >>> 1) As per spec you return a Promise on battery.js but to my knowledge
> we
> >>> don't have a fallback for ES6 Promises on platforms that don't
> support it
> >>> yet. I would like to know what other committers think about this
> problem.
> >>> 2) I think the old API and the new API can co-exist for a while
> before we
> >>> deprecate and remove the old one. I see that the new spec uses a
> different
> >>> method name so we should be fine here.
> >>>
> >>> Thanks,
> >>> Murat
> >>>
> >>> -----Original Message-----
> >>> From: Paul Contat [mailto:contat.paul@gmail.com]
> >>> Sent: Wednesday, July 1, 2015 12:38 AM
> >>> To: dev@cordova.apache.org
> >>> Subject: Introduction
> >>>
> >>> Hello everyone,
> >>>
> >>> My name is Paul Contat, and I'm an engineering student and currently
> doing
> >>> an internship at W3C focusing on aligning cordova API with W3C ones
> where
> >>> applicable, as part of the HTML5Apps EU project (
> >>>
> http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
> >>> )
> >>>
> >>> For my internship, I’m planning to contribute to the cordova project,
> >>> starting by the BatteryStatus API (
> >>> https://issues.apache.org/jira/browse/CB-6065) if it’s possible.
> >>>
> >>> I've just signed the ICLA, created an account on Apache JIRA so I’m
> ready
> >>> to start and submitted my first pull request:
> >>> https://github.com/apache/cordova-plugin-battery-status/pull/24
> >>>
> >>> I’m looking forward to feedback on whether I’m on the right path for
> >>> updating the Battery plugin API; I’m in particular interested to
> understand
> >>> if and how the current API should be deprecated once we get to a stage
> >>> where the new API is deemed in a good enough shape.
> >>>
> >>> Best regards,
> >>> Paul
> >>
> >>
> >>
> > --
> > Tyler Freeman
> > CTO, Tappur
> > http://tappur.co
> >
> > Sent from mobile
> >
>
Re: Introduction
Posted by Brian LeRoux <b...@brian.io>.
exactly so and by all means please feel free to use that, bluebird, rsvp,
q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
though I suggest one limits the scope to the other 200+ libraries claiming
A+ support! [2]
;P
[1] https://www.npmjs.com/search?q=Promise
[2] https://www.npmjs.com/search?q=Promise+A%2B
On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co> wrote:
> I'd just like to mention that jQuery has promises built-in as the
> $.Deferred object. It's not quite the same as the official Promises spec,
> but can be used similarly in most cases.
>
>
> On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote:
>>
>> We experimented with Promise polyfills and had nothing but trouble. I'd
>> like to preface by saying: lets not get into a theory war. Some people like
>> promises (fine) and some do not (also fine). My stance is that we should
>> leave that choice up to our end users.
>>
>> Lets throw some facts out to colour things.
>>
>> 1. Promises are a spec that will land in browsers natively [1]
>> 2. Promises as a concept have MANY polyfill implementations
>> 3. The polyfill landscape is largely divergent and implement different
>> flavors of the concept
>>
>> Since we implement a User Agent we *could* polyfill to spec. As a plugin.
>> (Jake's is probably best [2]) I'd be in favor of this and making that THE
>> plugin dep for companion plugins that require Promises. The problem with
>> this is #3. If we have a window.Promise it could be clobbered by a user
>> that is not super aware of how things are composed under the hood. If it
>> *could* happen guess what: it will. Some frameworks even force the idea of
>> Promises that may not be totally on spec. Older jQuery and Ember come to
>> mind.
>>
>> The other way to solve this problem is patience. This is the path I am most
>> in favor of. Lets wait out the native implementation to land in the various
>> webviews and at such time we can start using those.
>>
>> Plugins really should wrap device and operating system API's (in my
>> opinion) and we should leave library code for the user land to figure out.
>> The Promise API *is a library* until such time as it has been implemented
>> into the language runtimes natively (and not just speculatively
>> standardized). Ok I guess faltered into the theory war part there. ;)
>>
>> [1] https://promisesaplus.com/
>> [2] https://github.com/jakearchibald/es6-promise
>>
>>
>>
>>
>> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <mu...@microsoft.com> wrote:
>>
>> Hey Paul,
>>> Welcome to Cordova! I've looked at your changes on github and have some
>>> early feedback.
>>>
>>> 1) As per spec you return a Promise on battery.js but to my knowledge we
>>> don't have a fallback for ES6 Promises on platforms that don't support it
>>> yet. I would like to know what other committers think about this problem.
>>> 2) I think the old API and the new API can co-exist for a while before we
>>> deprecate and remove the old one. I see that the new spec uses a different
>>> method name so we should be fine here.
>>>
>>> Thanks,
>>> Murat
>>>
>>> -----Original Message-----
>>> From: Paul Contat [mailto:contat.paul@gmail.com]
>>> Sent: Wednesday, July 1, 2015 12:38 AM
>>> To: dev@cordova.apache.org
>>> Subject: Introduction
>>>
>>> Hello everyone,
>>>
>>> My name is Paul Contat, and I'm an engineering student and currently doing
>>> an internship at W3C focusing on aligning cordova API with W3C ones where
>>> applicable, as part of the HTML5Apps EU project (
>>> http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
>>> )
>>>
>>> For my internship, I’m planning to contribute to the cordova project,
>>> starting by the BatteryStatus API (
>>> https://issues.apache.org/jira/browse/CB-6065) if it’s possible.
>>>
>>> I've just signed the ICLA, created an account on Apache JIRA so I’m ready
>>> to start and submitted my first pull request:
>>> https://github.com/apache/cordova-plugin-battery-status/pull/24
>>>
>>> I’m looking forward to feedback on whether I’m on the right path for
>>> updating the Battery plugin API; I’m in particular interested to understand
>>> if and how the current API should be deprecated once we get to a stage
>>> where the new API is deemed in a good enough shape.
>>>
>>> Best regards,
>>> Paul
>>
>>
>>
> --
> Tyler Freeman
> CTO, Tappur
> http://tappur.co
>
> Sent from mobile
>
Re: Introduction
Posted by Brian LeRoux <b...@brian.io>.
We experimented with Promise polyfills and had nothing but trouble. I'd
like to preface by saying: lets not get into a theory war. Some people like
promises (fine) and some do not (also fine). My stance is that we should
leave that choice up to our end users.
Lets throw some facts out to colour things.
1. Promises are a spec that will land in browsers natively [1]
2. Promises as a concept have MANY polyfill implementations
3. The polyfill landscape is largely divergent and implement different
flavors of the concept
Since we implement a User Agent we *could* polyfill to spec. As a plugin.
(Jake's is probably best [2]) I'd be in favor of this and making that THE
plugin dep for companion plugins that require Promises. The problem with
this is #3. If we have a window.Promise it could be clobbered by a user
that is not super aware of how things are composed under the hood. If it
*could* happen guess what: it will. Some frameworks even force the idea of
Promises that may not be totally on spec. Older jQuery and Ember come to
mind.
The other way to solve this problem is patience. This is the path I am most
in favor of. Lets wait out the native implementation to land in the various
webviews and at such time we can start using those.
Plugins really should wrap device and operating system API's (in my
opinion) and we should leave library code for the user land to figure out.
The Promise API *is a library* until such time as it has been implemented
into the language runtimes natively (and not just speculatively
standardized). Ok I guess faltered into the theory war part there. ;)
[1] https://promisesaplus.com/
[2] https://github.com/jakearchibald/es6-promise
On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <mu...@microsoft.com> wrote:
> Hey Paul,
> Welcome to Cordova! I've looked at your changes on github and have some
> early feedback.
>
> 1) As per spec you return a Promise on battery.js but to my knowledge we
> don't have a fallback for ES6 Promises on platforms that don't support it
> yet. I would like to know what other committers think about this problem.
> 2) I think the old API and the new API can co-exist for a while before we
> deprecate and remove the old one. I see that the new spec uses a different
> method name so we should be fine here.
>
> Thanks,
> Murat
>
> -----Original Message-----
> From: Paul Contat [mailto:contat.paul@gmail.com]
> Sent: Wednesday, July 1, 2015 12:38 AM
> To: dev@cordova.apache.org
> Subject: Introduction
>
> Hello everyone,
>
> My name is Paul Contat, and I'm an engineering student and currently doing
> an internship at W3C focusing on aligning cordova API with W3C ones where
> applicable, as part of the HTML5Apps EU project (
> http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
> )
>
> For my internship, I’m planning to contribute to the cordova project,
> starting by the BatteryStatus API (
> https://issues.apache.org/jira/browse/CB-6065) if it’s possible.
>
> I've just signed the ICLA, created an account on Apache JIRA so I’m ready
> to start and submitted my first pull request:
> https://github.com/apache/cordova-plugin-battery-status/pull/24
>
> I’m looking forward to feedback on whether I’m on the right path for
> updating the Battery plugin API; I’m in particular interested to understand
> if and how the current API should be deprecated once we get to a stage
> where the new API is deemed in a good enough shape.
>
> Best regards,
> Paul
>
RE: Introduction
Posted by Murat Sutunc <mu...@microsoft.com>.
Hey Paul,
Welcome to Cordova! I've looked at your changes on github and have some early feedback.
1) As per spec you return a Promise on battery.js but to my knowledge we don't have a fallback for ES6 Promises on platforms that don't support it yet. I would like to know what other committers think about this problem.
2) I think the old API and the new API can co-exist for a while before we deprecate and remove the old one. I see that the new spec uses a different method name so we should be fine here.
Thanks,
Murat
-----Original Message-----
From: Paul Contat [mailto:contat.paul@gmail.com]
Sent: Wednesday, July 1, 2015 12:38 AM
To: dev@cordova.apache.org
Subject: Introduction
Hello everyone,
My name is Paul Contat, and I'm an engineering student and currently doing an internship at W3C focusing on aligning cordova API with W3C ones where applicable, as part of the HTML5Apps EU project ( http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/
)
For my internship, I’m planning to contribute to the cordova project, starting by the BatteryStatus API (
https://issues.apache.org/jira/browse/CB-6065) if it’s possible.
I've just signed the ICLA, created an account on Apache JIRA so I’m ready to start and submitted my first pull request:
https://github.com/apache/cordova-plugin-battery-status/pull/24
I’m looking forward to feedback on whether I’m on the right path for updating the Battery plugin API; I’m in particular interested to understand if and how the current API should be deprecated once we get to a stage where the new API is deemed in a good enough shape.
Best regards,
Paul