Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
MIME-Version: 1.0
References: 
 <CAMWJNPyJgSdag5eb5RMgkMu4nUfOZcO1P_2kON5DOQSDjdb9vw@mail.gmail.com>
 <SN2PR03MB0326607B9302BA46BBA3E8EB8920@SN2PR03MB032.namprd03.prod.outlook.com>
 <CADVgkyMUXYG35j4ewtyX+HYa4_gdambtdQrZyJjVPmUUjeuQZA@mail.gmail.com>
 <14C61194-7653-4478-98FF-410D92FA0FA4@tappur.co>
 <CADVgkyN9d8+i7On7VWx0fU_Jx99CWBmbQRdwe+Sekj+dvXDhZQ@mail.gmail.com>
 <CAOBL_k7NhV9xOp9OF=A0nRbmQuGAPJvyVr=wp4XMXfr41cv5Og@mail.gmail.com>
 <CAG5ZNwVUPfup6ybSwVaQAHJOOhn_TSeW12jGp-9Kwo1XB5y9BA@mail.gmail.com>
In-Reply-To: 
 <CAG5ZNwVUPfup6ybSwVaQAHJOOhn_TSeW12jGp-9Kwo1XB5y9BA@mail.gmail.com>
From: Joe Bowser <bowserj@gmail.com>
Date: Tue, 07 Jul 2015 19:25:10 +0000
Message-ID: 
 <CAOBL_k5ZPhgstic5aH0ROcV-xjgZUBu9nNSv5WFOVrecbQxW2A@mail.gmail.com>
Subject: Re: Introduction
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Cc: Tyler Freeman <tyler@tappur.co>
Content-Type: multipart/alternative; boundary=001a113d3e02a61702051a4dfb83

--001a113d3e02a61702051a4dfb83
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <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 <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 <bowserj@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=3DPromise
> > [2] https://www.npmjs.com/search?q=3DPromise+A%2B
> >
> >
> > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <tyler@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 tha=
t
> > 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. I=
f
> 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 com=
e
> 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 figur=
e
> > 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 one=
s
> > 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=E2=80=99m planning to contribute to the cordo=
va
> project,
> > >>>  starting by the BatteryStatus API (
> > >>>  https://issues.apache.org/jira/browse/CB-6065) if it=E2=80=99s pos=
sible.
> > >>>
> > >>>  I've just signed the ICLA, created an account on Apache JIRA so I=
=E2=80=99m
> > ready
> > >>>  to start and submitted my first pull request:
> > >>>  https://github.com/apache/cordova-plugin-battery-status/pull/24
> > >>>
> > >>>  I=E2=80=99m looking forward to feedback on whether I=E2=80=99m on =
the right path
for
> > >>>  updating the Battery plugin API; I=E2=80=99m in particular interes=
ted 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
> > >
> >
>

--001a113d3e02a61702051a4dfb83--