Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAG5ZNwVUPfup6ybSwVaQAHJOOhn_TSeW12jGp-9Kwo1XB5y9BA@mail.gmail.com>
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>
Date: Tue, 7 Jul 2015 12:21:52 -0700
Message-ID: 
 <CAKP6k2s-MDVBOc+3fS6qpptd-3qAcOeEw3iHc=R2PPzBLUCDug@mail.gmail.com>
Subject: Re: Introduction
From: Jesse <purplecabbage@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a113c409c4a090a051a4def4b

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

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.co=
m
> wrote:

> It's only supported by android 5 webview (12% share right now), so I thin=
k
> 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 <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 Geolocati=
on
> > 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
> that
> > > THE
> > > >> plugin dep for companion plugins that require Promises. The proble=
m
> > 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 th=
e
> > > various
> > > >> webviews and at such time we can start using those.
> > > >>
> > > >> Plugins really should wrap device and operating system API's (in m=
y
> > > >> 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.co=
m
> >
> > > wrote:
> > > >>
> > > >>  Hey Paul,
> > > >>>  Welcome to Cordova! I've looked at your changes on github and ha=
ve
> > > 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-ap=
is/
> > > >>>  )
> > > >>>
> > > >>>  For my internship, I=E2=80=99m planning to contribute to the cor=
dova
> > project,
> > > >>>  starting by the BatteryStatus API (
> > > >>>  https://issues.apache.org/jira/browse/CB-6065) if it=E2=80=99s p=
ossible.
> > > >>>
> > > >>>  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 o=
n the right path
> for
> > > >>>  updating the Battery plugin API; I=E2=80=99m in particular inter=
ested 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
> > > >
> > >
> >
>

--001a113c409c4a090a051a4def4b--