Re: Cordova website redesign

[Brian LeRoux]

Well said, and ya updated typeface looks slick. 
On Wed, Oct 7, 2015 at 6:10 PM Ryan J. Salva  wrote:

> I'm personally a big fan of Ben's proposal. The typography really stands
> out and gives the brand a strong, updated and modern presence. I know
> there's a lot of pride in the heritage of the logo, and for that reason I
> wouldn't dream of losing our beloved robot. However, the typography is a
> different story.
>
> Is it absolutely necessary? Well... that really depends on your
> perspective. From talking with many of you and other developers at
> conferences and events over the past year, I've heard a repeating theme
> that Cordova has a public-perception problem. A typography update won't
> change that perception by itself, but it will demonstrate that Cordova
> isn't staying still... that the project is evolving, growing and improving.
>
> 
> rjs
>
> Ryan J. Salva  |  Principal Program Manager Lead
> Visual Studio Tools for Apache Cordova
> rsa...@microsoft.com
> 206 612 5079 mobile
>
>
>
> -Original Message-
> From: Tommy-Carlos Williams [mailto:to...@devgeeks.org]
> Sent: Wednesday, October 7, 2015 12:21 PM
> To: dev@cordova.apache.org
> Subject: Re: Cordova website redesign
>
> Yeah... I kinda fell into the "not sure, wait and see what others thought"
> category on this one.
>
> I would also like more discussion unless everyone really has no opinion.
>
> > On 8 Oct 2015, at 05:42, Jesse  wrote:
> >
> > I would suggest that the lack of response on the logo change means we
> don't need it.
> > I think there should at least be some discussion before moving on it.
> >
> >> On Oct 7, 2015, at 11:31 AM, Brad Gashler  wrote:
> >>
> >> Hi Everyone,
> >>
> >> I wanted to follow up on the branding changes proposed by Ben Sperry
> (his email is included below).
> >>
> >> I’m planning on implementing his changes, since no objections were
> raised.  This includes the new logo, with its modern typeface, as shown in
> picture A below.  Also, we may replace the background image with the simple
> gradient as shown in picture B below.  Please let me know if there are any
> concerns replacing this background image.
> >>
> >> Thanks,
> >>
> >> Brad Gashler
> >>
> >>
> >> A) New logo only
> >>
> >>
> >>
> >> B) New logo and new gradient background
> >>
> >>
> >>
> >>
> >> -Original Message-
> >> From: Ben Sperry [mailto:b...@ionic.io]
> >> Sent: Thursday, September 24, 2015 1:17 PM
> >> To: dev@cordova.apache.org
> >> Subject: Re: Cordova website redesign
> >>
> >> I really like where this update is going, and what it signals to the
> >> community: Cordova is a legitimate, modern tech solution that's still
> very much alive and growing. The website look/feel has a lot of confidence,
> love it!
> >>
> >> I'm curious what thoughts are around a Cordova logo update itself. I
> >> put together a version that I thought might support the evolution of
> >> Cordova into a more modern looking brand. Would love feedback on this
> >> early logo update mockup: regular
> >>  >> c-io-assets.s3.amazonaws.com%2fcordova%2fcordova-logo-3d-proposal.png
> >> =01%7c01%7cbradga%40microsoft.com%7c46d14102d64c4e5de06408d2c51d
> >> 409d%7c72f988bf86f141af91ab2d7cd011db47%7c1=oKVaCThqWbhTgak3efA
> >> aM%2f3f1d1wGyqazXPdboZjsAk%3d>
> >> / flat
> >>  >> c-io-assets.s3.amazonaws.com%2fcordova%2fcordova-logo-flat-proposal.p
> >> ng=01%7c01%7cbradga%40microsoft.com%7c46d14102d64c4e5de06408d2c5
> >> 1d409d%7c72f988bf86f141af91ab2d7cd011db47%7c1=vyJ80acz9%2bDPk4Y
> >> ZuidiCPknjl%2fwOCKN7KMyxem5jJg%3d>
> >>
> >> A few things to note: The typeface is really the big update - the
> little robot logo itself can stay the same (because he is awesome). The
> existing typeface is just plain-old Helvetica, which is totally fine, but
> can sometimes feel empty of any personality or uniqueness. My suggestion is
> simply to update it to a more contemporary, custom typeface (in this case,
> Brandon Text <
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhvdfonts.com%2fbrandontext%2f=01%7c01%7cbradga%40microsoft.com%7c46d14102d64c4e5de06408d2c51d409d%7c72f988bf86f141af91ab2d7cd011db47%7c1=qFtGPbwutLEDyHils6NLuVjZrmSedM%2bPAM%2fv42v1E4s%3d
> >).
> >>
> >> Would love to hear any and all thoughts on this!
> >>
> >>> On Thu, Sep 24, 2015 at 1:25 PM, Frederico Galvão <
> frederico.gal...@pontoget.com.br> wrote:
> >>>
> >>> Looks great indeed, nice job!
> >>>
> >>> One thing I noticed is that
> >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fpro
> >>> je
> >>> cts.apache.org%2fproject.html%3fcordova=01%7c01%7cbradga%40micr
> >>> os
> >>> oft.com%7c46d14102d64c4e5de06408d2c51d409d%7c72f988bf86f141af91ab2d7
> >>> cd 011db47%7c1=ZeVerioKs9Eu8faVlumAOu0bmmXPyqq6tJ5gsXU2KNM%3d
> >>> seems very outdated.
> >>>
> 

Re: Deploying New Cordova Website

[Brian LeRoux]

Lazy consensus is Apache apparatus too. Announce intent, if there is no
disagreement: consider it assent.

That said, I do think we could safely upgrade to emoji for all vote-like
things.

✨
On Sat, Oct 3, 2015 at 1:45 AM Tommy Williams  wrote:

> +1 to what Jesse said...
>
> I don’t think we need the full apache apparatus to be invoked, but
> consensus by vote would be a worthy goal even for things like this.
>
>
> On 3 October 2015 at 14:49:10, Jesse (purplecabb...@gmail.com) wrote:
>
> Just saying that we need to be sure we agree on the changes we implement,
> whether they are marketing, messaging, design or whatever ... as a
> committee this has typically been done by vote.
>
>
> My team is hiring!
> @purplecabbage
> risingj.com
>
> On Fri, Oct 2, 2015 at 7:34 PM, Carlos Santana 
> wrote:
>
> > Kidding aside I agree with Steve, I see this as community assets vs. the
> > code that we release needs to be verify for certain criteria (testing,
> hash
> > check, etc)
> >
> > - Carlos
> > Sent from my iPhone 6s
> >
> > > On Oct 2, 2015, at 10:27 PM, Steven Gill 
> wrote:
> > >
> > > We don't vote for things we aren't distributing as a release. Never
> voted
> > > for a website change before, major or minor.
> > >
> > > We don't vote on docs either and didn't vote when we released
> > > plugins.cordova.io.
> > >
> > > No need to add unnecessary process and delay.
> > >
> > >> On Fri, Oct 2, 2015 at 7:00 PM, Carlos Santana 
> > wrote:
> > >>
> > >> Does that mean no hero picture of me and a guitar :-( on the front
> page
> > >>
> > >> - Carlos
> > >> Sent from my iPhone
> > >>
> > >>> On Oct 2, 2015, at 9:49 PM, Jesse  wrote:
> > >>>
> > >>> +1
> > >>> ... and we probably should vote for major changes.
> > >>>
> >  On Oct 2, 2015, at 6:31 PM, Nikhil Khandelwal <
> nikhi...@microsoft.com
> > >
> > >> wrote:
> > 
> >  Wohoo! Let's do it!
> > 
> >  -Nikhil
> > 
> >  -Original Message-
> >  From: Carlos Santana [mailto:csantan...@gmail.com]
> >  Sent: Friday, October 2, 2015 6:06 PM
> >  To: dev@cordova.apache.org
> >  Subject: Re: Deploying New Cordova Website
> > 
> >  But I wanted to +1
> > 
> >  Launched !!
> > 
> >  - Carlos
> >  Sent from my iPhone
> > 
> > > On Oct 2, 2015, at 8:21 PM, Steven Gill 
> > >> wrote:
> > >
> > > Sweet!
> > >
> > > You don't have to vote for website updates.
> > >
> > > I can update the cordova DNS. Just let me know what the links are
> and
> > > when you want it done.
> > >
> > > Thanks!
> > >
> > > Let me know if you want any assistance.
> > >
> > > On Fri, Oct 2, 2015 at 3:45 PM, Dmitry Blotsky
> > > 
> > > wrote:
> > >
> > >> Hey folks,
> > >>
> > >> I’m planning to deploy the new website on top of the old one
> over
> > >> this weekend (blog posts are synchronised on every deploy, so they
> > >> will be up to date). Any objections to this? Should I call for a
> > vote?
> > >>
> > >> Some things that will need to happen shortly after the deployment:
> > >> - Pointing
> > >>
> > https://na01.safelinks.protection.outlook.com/?url=plugins.cordova.io
> > >> =01%7c01%7cnikhilkh%40microsoft.com
> > %7c99e748bfefa44861245308d2cb
> > >>
> > 8edff7%7c72f988bf86f141af91ab2d7cd011db47%7c1=NcnPnk82TZniP%2fi
> > >> Cj9E1cNFL29FGWMO1djsvtceRV%2fo%3d to
> > >>
> > https://na01.safelinks.protection.outlook.com/?url=cordova.apache.org
> > >> %2fplugins=01%7c01%7cnikhilkh%40microsoft.com
> > %7c99e748bfefa44861
> > >>
> > 245308d2cb8edff7%7c72f988bf86f141af91ab2d7cd011db47%7c1=CN7amiG
> > >> uuxUyUVJ6031Vc9fy6dlBR%2fS8iI9tSv%2b3TuU%3d
> > >> - Pointing
> > >>
> > https://na01.safelinks.protection.outlook.com/?url=docs.cordova.io
> > >> ta=01%7c01%7cnikhilkh%40microsoft.com
> > %7c99e748bfefa44861245308d2cb8ed
> > >>
> > ff7%7c72f988bf86f141af91ab2d7cd011db47%7c1=D3vMNPcGKbEgDtYIvtJs
> > >> LEEfs9bFvFsF2fIDhM%2frWzM%3d to
> > >>
> > https://na01.safelinks.protection.outlook.com/?url=cordova.apache.org
> > >> %2fdocs%2fen=01%7c01%7cnikhilkh%40microsoft.com
> > %7c99e748bfefa448
> > >>
> > 61245308d2cb8edff7%7c72f988bf86f141af91ab2d7cd011db47%7c1=SZbwT
> > >> k8lYSeVZ4KgIDD2txrFdwXoMg2n01stMJRVMpQ%3d
> > >> - Merging all the code back into master
> > >> - Replacing the files on Crowdin with the new files
> > >>
> > >> Kindly,
> > >> Dmitry
> > >>
> > -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > 
> > 
> -
> >  To 

Re: Understanding the Cordova developer better - Cordova developer survey

[Brian LeRoux]

Surveys remind me of that Henry Ford quote. Doesn't hurt to do them but I
would not take the responses too seriously or we will end up with a faster
horse. ;)
On Tue, Sep 29, 2015 at 10:39 PM Parashuram N 
wrote:

> Hey,
>
> We have had multiple discussions on this mailing list about Cordova users
> and various issues they have with Cordova.
> As we draw closer to the Cordova Face to Face meeting, I thought it would
> be interesting to try to get some data and understand our users better when
> we dive deeper into some of the topics. To this end, as a first attempt, I
> created a survey that we could send out to developers who use Cordova for
> creating the apps.
>
> The survey is available here at
> https://apachecordovabot.typeform.com/to/BCc5co. You can use the
> apache...@gmail.com credentials (in committer
> SVN) to change the questions or add more questions directly.
>
> The aim here is to understand how they use Cordova, and what they like and
> hate about it.
>
> What do you guys think about doing this ?  - would this be useful ?
> Are there more questions we would like to ask our developers ?
>

Re: [DISCUSS] CORDOVA AND LIVERELOAD

[Brian LeRoux]

also a -1 to core / most of the downstreams have livereload or hotreload
baked into their respective frameworks

On Wed, Aug 26, 2015 at 10:59 AM, Carlos Santana csantan...@gmail.com
wrote:

 -1  to add to cordova-lib

 maybe to be a default plugin, but I'm with Jesse with this one lets not add
 yet and lets be agile and iterate based on community feedback,

 there might be other better way to add the plugin than the default template
 (i.e. cordova tool add livereload, etc..) lets see how it goes for now

 Currently no a big fan of having the whitelist added by default, I
 understand all the background from it but as high level view a plugin is
 something you add is not something that comes included.




 On Wed, Aug 26, 2015 at 1:44 PM Jesse purplecabb...@gmail.com wrote:

  Personally, I would rather we didn't force it thru.
  We don't include cordova-plugin-console which is a huge ease-of-use
  improvement, and it is tiny, and more arguably should be built in.
  If we get through a few versions, and it proves popular, and is working
  well, I may change my mind, but I would rather soft launch it instead of
  suddenly springing new developer debt on the project.
 
 
 
 
 
 
  My team is hiring!
  @purplecabbage
  risingj.com
 
  On Wed, Aug 26, 2015 at 10:23 AM, Mefire O. ommen...@microsoft.com
  wrote:
 
  
   Also, to improve DISCOVERABILITY and EASE OF USE, I was thinking about
   making the LiveReload tooling part of the default Cordova experience by
   including the plugin in the default project template or by it being in
   cordova-lib ( depending on what architectural choice we make).
  
   It would only be turned on by including the --livereload from the CLI.
  
   Any thoughts ?
  
  
   - https://github.com/MSOpenTech/cordova-cli/commits/LiveReload
   - https://github.com/omefire/cordova-plugin-livereload
  
  
   Thanks,
   Mefire
  
   -Original Message-
   From: Mefire O. [mailto:ommen...@microsoft.com]
   Sent: Monday, August 24, 2015 11:01 AM
   To: dev@cordova.apache.org
   Subject: RE: [DISCUSS] CORDOVA AND LIVERELOAD
  
   Thanks for the feedback, guys.
  
   As a result of your comments, I've done the following changes :
  
   -  Pivoted towards a plugin-based architecture :
  
 
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fomefire%2fcordova-plugin-livereloaddata=01%7c01%7commenjik%40microsoft.com%7ca5385b13d97b4d71e84f08d2acae110d%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=6YrzZ4dCG8FttPF150r%2f00G2gfB8%2fqGwLax41boeVo4%3d
   - The plugin is going to be activated only when the '--livereload'
 option
   is passed to the CLI.
   - I forgot to include the changes to cordova-cli to accommodate the
   --livereload flag :
  
 
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fMSOpenTech%2fcordova-cli%2fcommits%2fLiveReloaddata=01%7c01%7commenjik%40microsoft.com%7ca5385b13d97b4d71e84f08d2acae110d%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=wLWcK7014onZyfFCfbI4PKGTcjBLHq2TWX8uGPzfZRs%3d
  
  
   Thanks,
   Mefire
  
   -Original Message-
   From: Carlos Santana [mailto:csantan...@gmail.com]
   Sent: Friday, August 21, 2015 5:28 PM
   To: dev@cordova.apache.org
   Subject: Re: [DISCUSS] CORDOVA AND LIVERELOAD
  
   This is so awesome, as working on a downstream I have being debating if
   this is something I should add to my downstream.
   I think this is standard stuff that cordova should enable but not
 include
   in core, it should be a plugin.
  
   maybe we should have a tag for  plugins that are only for tooling,
  meaning
   that are easy to take out or ignore when building/running a production
  app.
   or be dormant until the --livereload is pass in the command line for
   emulate or run.
  
   I really think BrowserSync is rad, and having a plugin implemented by
   cordova is good as reference implementation if others want to
 implement a
   different one. but I think we can provide that satisfy the need of most
   developers.
  
   But I think the cordova-cli should document and have some convention
   support the developer to emulate/run with --livereload. then  a plugin
  can
   declare that it provides the livereload feature, and detect that
   --livereload was pass do it's magic
  
  
  
   On Fri, Aug 21, 2015 at 5:14 PM Jesse purplecabb...@gmail.com wrote:
  
This is really cool work, and will absolutely help developers.
Personally, I prefer the plugin approach.
Which library is chosen is entirely up to the plugin author, but I
really like BrowserSync!
   
In all cases, I believe it is important to try NOT to add features to
cordova. The ultimate goal is have cordova be intrinsic to all device
platforms, and the more things we build into cordova, the more
difficult this becomes. Others may have different views, and I am
anxious to hear them, but that is the way I have always looked at it.
   
   
   
   
   
My team is hiring!
@purplecabbage
   
 

Re: [VOTE] 4.0.0 Browser Release

[Brian LeRoux]

+1

On Mon, Aug 17, 2015 at 4:12 PM, Steven Gill stevengil...@gmail.com wrote:

 Please review and vote on this 4.0.0 Browser Release
 by replying to this email (and keep discussion on the DISCUSS thread)

 Release issue: https://issues.apache.org/jira/browse/CB-9491

 The archive has been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-9491

 The package was published from its corresponding git tag:
 cordova-browser: 4.0.0 (580a0c6eb7)

 Note that you can test it out via:

 cordova platform add https://github.com/apache/cordova-browser#4.0.0

 Upon a successful vote I will upload the archive to dist/, publish it
 to NPM, and post the blog post.

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and
 subdependencies have Apache-compatible licenses
 * Created a simple browser hello world app using the cli.

Re: [DISCUSS] Docs improvements

[Brian LeRoux]

Sgtm!
On Wed, Aug 5, 2015 at 6:05 AM Andrey Kurdumov kant2...@googlemail.com
wrote:

 Hi all,

 I want to made small improvements to the current version of Docs meanwhile
 Dmitry Blotsky working on Jekill. Want do discuss proposed changes before
 implementing them.

 My ultimate goal is to be able publish each version of docs/language
 independently. I want faster releases for fixes in translation and docs,
 and be able fix older docs too.
 Please correct me if this is not possible with existing infrastructure.

 Here list of things:
 1. Separate version dropdown on two parts. Language and version. Right now
 if you try select non English version you have to scroll over English
 versions a lot.
 2. Provide warning about not latest documentation (Using JS) Will put
 current version in the docs and check some JSON fiels which will list all
 versions per language.
 3. Provide No Javascript version of langauge selector checkboxes.
 4. Create new source file for language TOC.md which will be used for
 generating left sidebar in the existing docs design. So far, that TOC would
 duplicate Overview page as it is now, but want to improve it further later
 on. That's breaking change which affects older docs, so I will create such
 TOC files for these old docs too, and verify that existing output would be
 exactly the same as it is now.

 To implement that I want to create new shared area on the website
 `docs/common` folder and `docs/lang/common` folder. That folders will
 contains
 a) `docs/common/langdata.json` - JSON with list of languages + latest
 version per language
 b) `docs/ru/versionselector.html` - HTML file where use could change
 language or version when JS is disabled in browser.

 I extremely want create 1 and 2 before next release. That's rather small
 changes, but need community agreement on implementing that.

Re: [DISCUSS] Website Repo

[Brian LeRoux]

On Tue, Jul 21, 2015 at 2:09 AM Dmitry Blotsky dblot...@microsoft.com
wrote:

 Hey folks,

 In lieu of the changes coming to the docs and the website design proposed
 at the hangout, I’d like to consolidate our docs, blog, and website under
 one Git repo. Right now we have some code in several Git repos (docs, blog
 posts), and some in the SVN repo (website itself). I’d like to move for one
 Git repo to contain them all, and to use the SVN only for deployment. For
 this, I’d like to move to create either github.com/cordova/cordova-website
 http://github.com/cordova/cordova-website or
 github.com/apache/cordova-websitehttp://github.com/apache/cordova-website
 .

 What are your kind thoughts on this matter?

 Kindly,
 Dmitry

Re: [DISCUSS] Website Repo

[Brian LeRoux]

thumbs up! (idk what happened)

On Tue, Jul 21, 2015 at 11:55 AM, Jesse purplecabb...@gmail.com wrote:

 Brian? was that a thumbs-up or a poo-poo?
 Not seeing your emoji ...

 I agree with Nikhil that we should optimize for contribution, and probably
 stay within the apache org at github.


 My team is hiring!
 @purplecabbage
 risingj.com

 On Tue, Jul 21, 2015 at 10:53 AM, Nikhil Khandelwal 
 nikhi...@microsoft.com
 wrote:

  'Cordova' github org is good for committers, but it's unclear we have the
  right basis (CLAs etc.) for accepting contributions there.
 
  Even though Apache org does not provide us with some features like labels
  (and that might change soon), keeping it under that org might be a good
  path forward.
 
  We should really optimize the structure to encourage contribution,
  especially to our docs (as they often go stale and its easiest to have
 devs
  contribute to). Cordova-docs repo is currently the place to do that. I'm
  concerned changing that will be a disruptive to contributions in the
 short
  term. If we can do a transfer (github redirect) that might be good - I
 know
  github supports that. Another alternative is to use the cordova-docs repo
  itself and add website content there.
 
  Thanks,
  Nikhil
 
 
  -Original Message-
  From: Brian LeRoux [mailto:b...@brian.io]
  Sent: Tuesday, July 21, 2015 9:28 AM
  To: dev@cordova.apache.org
  Subject: Re: [DISCUSS] Website Repo
 
  On Tue, Jul 21, 2015 at 2:09 AM Dmitry Blotsky dblot...@microsoft.com
  wrote:
 
   Hey folks,
  
   In lieu of the changes coming to the docs and the website design
   proposed at the hangout, I’d like to consolidate our docs, blog, and
   website under one Git repo. Right now we have some code in several Git
   repos (docs, blog posts), and some in the SVN repo (website itself).
   I’d like to move for one Git repo to contain them all, and to use the
   SVN only for deployment. For this, I’d like to move to create either
   github.com/cordova/cordova-website
   http://github.com/cordova/cordova-website or
   github.com/apache/cordova-websitehttp://github.com/apache/cordova-web
   site
   .
  
   What are your kind thoughts on this matter?
  
   Kindly,
   Dmitry
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 

Re: Introduction

[Brian LeRoux]

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 mura...@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.p...@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

[Brian LeRoux]

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 mura...@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.p...@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

[Brian LeRoux]

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 stevengil...@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 
 jcesarmob...@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 bows...@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 
 mura...@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

Re: June 2015 Board Report

[Brian LeRoux]

looks great shaz: thank you!

On Thu, Jun 11, 2015 at 4:25 PM, Shazron shaz...@gmail.com wrote:

 https://github.com/cordova/apache-board-reports/blob/master/2015/2015-06.md

 Let me know your comments, if any -- this time I just used the automatic
 tool at reporter.apache.org which collects stats that I had been doing
 manually.

 Releases still have to be added manually using that tool.

Re: Sticky Channels

[Brian LeRoux]

big -1 on promises from me; they've only been a pain for us thus far (ask
steve about the plugman debugging

maybe when they're native. mybe.

On Tue, Jun 9, 2015 at 7:27 AM, Ian Clelland iclell...@chromium.org wrote:

 On Tue, Jun 9, 2015 at 10:19 AM, Andrew Grieve agri...@chromium.org
 wrote:

  I think the only place sticky channels are used is for startup events
  (deviceready, nativeready, pluginsready, etc). I think you could probably
  change them to fire multiple times without breaking too much, but the
  semantics of that seem really strange to me (fire the most recent event,
 or
  all events? upon registering, but only to the newly added listener(s))
 
  They are not based on any standard, so it might be nice not to use them,
  and instead use standard events (e.g. cordova.fireWindowEvent). As long
 as
  we promise not to fire them until after deviceready, apps should be able
 to
  register listeners reliably.
 

 This was an area that I was hoping to leverage to use promises instead,
 back when we were discussing baking those into cordova.js -- it would be a
 major change from the existing way of doing things, but sticky channels are
 closer in spirit to promises than they are to events, I think.

 It's very similar to the service worker `ready` attribute -- before the
 worker is active, it returns a promise that asynchronously waits for
 everything to be ready, and then fires. After the worker is already active,
 the promise resolves immediately, just like deviceready does if you attach
 a listener after Cordova has initialized.


 
  One other data point for this is that I dealt with the as-a-service vs.
  as-a-launch in
  https://github.com/MobileChromeApps/cordova-plugin-background-app. In
 this
  model, I set a property before each resume / deviceready that can be
  queried to find out the app's state. Could possibly do similar for
 intents
  (but would need an event as well since they can come at any time, not
 just
  on start-up)
 
  On Fri, Jun 5, 2015 at 7:18 PM, Jesse purplecabb...@gmail.com wrote:
 
   I have been looking into unifying launchParameters across devices so
 that
   all cordova apps can get some context of how they were
  launched/activated.
   This includes everything from a url/protocol launch in another app, to
 a
   touch on a notification (toast,local,push,... )
  
   My intent was to add a channel for this, however I have had some issues
   with channels + stickiness.
  
   I wanted a channel that would call new subscribers immediately if it
 had
   already fired.  In our channel implementation this is what we call a
  sticky
   channel.  However, this particular channel may fire more than once, ie.
  we
   could be activated multiple times while running, or receive multiple
   notifications.
   The current implementation for sticky will only ever call subscribers
  once,
   and if I call fire() more than once, it actually removes it's
  subscribers.
   [1] So I cannot use this as is for my needs.
  
   So my questions are :
   1. Why is like this? Is there some standard or expectation that this is
   based on?
   2. Can I change it? What would be the impact of changing the behavior
 to
   have a sticky channel fire more than once, and keep its list of
   subscribers?
   3. Are there historical reasons that things are the way they are? The
  code
   has been through several major moves since it was written, so it is
   difficult to pin the original commit (Fil, Andrew? some merged pr?)  If
   there are historical reasons, are they still relevant?
  
   Please keep in mind too that I am not asking for the solution to my
   specific task, I can work around anything ... I am asking solely about
  the
   current channel-sticky implementation and it we should change it.
  
   Cheers,
 Jesse
  
  
   The current implementation
   [1]
  
 
 https://github.com/apache/cordova-js/blob/master/src/common/channel.js#L216
  
  
   @purplecabbage
   risingj.com
  
 

Re: Cordova Meetup/Beerup at WWDC?

[Brian LeRoux]

right on! lets plan a mini meetup this week!

On Fri, Jun 5, 2015 at 5:24 PM, Carlos Santana csantan...@gmail.com wrote:

 I will be in SF this week starting Sunday for WWDC, somehow I was able to
 get a ticket thru IBM ;-)

 I will be there Sunday to Friday, if anyone wants to meet to talk, hack,
 eat or drink let me know

 --
 Carlos Santana

Re: [DISCUSS] Deprecate --usegit flag

[Brian LeRoux]

+1

On Wed, Jun 3, 2015 at 12:17 PM, Jesse purplecabb...@gmail.com wrote:

 +1
 and using real git urls (should?) lets you install from branches/tags+other
 git repos and not just the mystical magical one that lives behind the flag.

 @purplecabbage
 risingj.com

 On Wed, Jun 3, 2015 at 12:05 PM, Steven Gill stevengil...@gmail.com
 wrote:

  Sounds like a good candidate for deprecation to me. I used --usegit in
 the
  old nightly builds I had running. But the custom git urls would work just
  as well.
 
  -Steve
 
  On Wed, Jun 3, 2015 at 11:44 AM, Mefire O. ommen...@microsoft.com
 wrote:
 
   Hi list,
   I think it's high time we deprecate the -usegit flag, whose intent was
 to
   provide apache git repos as an alternative source to install platforms
  (the
   default being npm).
  
   A little bit of background :
   In the past, there were two main sources from which to install a
  platform.
   You could fetch the platform to be installed from npm (the default).
   Or you could specify that the platform to be installed be fetched from
  the
   Apache git repo using -usegit : `cordova platform add android -usegit`.
  
   There are certain shortcomings to the -useflag :
  
   -It only works with Apache git repos. It doesn't support custom
   git repos.
  
e.g: It passes if the following is found in platformsConfig.json :
   `cordova platform add
   https://git-wip-us.apache.org/repos/asf?p=cordova-android.git`
  
e.g: the following would fail : `cordova platform add
   https://github.com/apache/cordova-android.git`
   https://github.com/apache/cordova-android.git%60
  
   -The code that implements it is complex and prone to bugs. e.g:
   https://github.com/apache/cordova-lib/pull/232
  
   -The git repo we want to fetch the platform from has to be
   manually added to the file platformsConfig.json.
  
  
   Suggested replacement:
   We've been supporting custom git-urls for a while now :
  
   -
  
 
 https://github.com/apache/cordova-lib/commit/811f6f72d74dfd2ca054553ae248f0831235f912
  
   -
  
 
 https://github.com/apache/cordova-lib/commit/4d2059452fa36dd510d9a949e150de840d336e04
  
   Using this feature, we can add platforms from any git repo using the
   following : `cordova platform add
   https://github.com/apache/cordova-android.git`
   https://github.com/apache/cordova-android.git%60
   It also supports specifying a custom branch : `cordova platform add
   https://github.com/apache/cordova-android.git#my_branch`
  
   So, I think this second feature can handle all the scenarios handled by
   -usegit and much more ...
  
   What I propose is phasing out the -usegit flag, over the next 6 months.
  
   Please, let me know your thoughts.
  
   Thanks,
   Mefire
  
  
 

Re: Best place to browse plugins

[Brian LeRoux]

Ray: you have commit rights. =)

On Mon, Jun 1, 2015 at 2:41 PM, Raymond Camden raymondcam...@gmail.com
wrote:

 Do we have a rough idea of how soon we will see the improvements on the NPM
 side? If it is 1-2 weeks, then I don't think it is a huge big deal, but if
 longer than that I think we have a problem with our uses. Right now there
 are *no* docs if they follow the links from docs.cordova.io. We all know
 where the docs can be found, and I blogged on it too, but for new users
 this is not ideal, and is pretty critical I think.

 Query - if the issue now is that the Markdown used by core plugins doesn't
 match the Markdown supported by npm, instead of waiting for npm to fix it,
 couldn't we just do the manual grunt work ourselves? I'd happily try to hit
 one of the files myself if so.

 On Mon, Jun 1, 2015 at 1:20 PM, Kerri Shotts kerrisho...@gmail.com
 wrote:

  Jörg,
 
  I disagree: the move to NPM was a good move. It might not be perfect yet
  (far from it), but NPM is apparently moving forward with making search
 and
  such easy. The description is an issue, yes, but that’s also being worked
  out (and only applies to core plugins — third party plugins should be
 just
  fine). Furthermore, it means that Cordova is no longer responsible for
  maintaining a repository, which quickly becomes nontrivial when you have
 a
  lot of people hitting it. NPM has far more resources in this regard than
  does Cordova.
 
  That said, I’m also all for implementing a plugin page like Gulp, Yeoman,
  etc. do, even if NPM gets better searching and the like, simply because,
 as
  you say, it gives an overview that can lead to inspiration. I prefer
 using
  Gulp’s list or Yeoman’s list over NPM’s site, but I’m also glad that NPM
 is
  being used to manage the packages. Nearly everything else I’m doing is on
  NPM now anyway, so it works out well for my workflow that Cordova’s
 plugins
  are now too. (Never mind that the platforms and the CLI have been there
 for
  some time.)
 
  This is completely separate from your issue with “good plugins”. NPM or
  Cordova’s registry will make no difference to that — you’re relying upon
  the skills and goodwill of third party developers to make plugins for
 you,
  and they will all be of varying quality with varying documentation.
 That’s
  a problem with Gulp, Yeoman, and every other tool that allows plugins. As
  to verification with versions and platforms, that’s always going to be up
  to the plugin owner, not the repository. I don’t really see any way
 around
  that as it would always be hit or miss with third party plugins.
 
 
 
 
  On May 30, 2015 at 4:49:08 PM, Joerg Holz (h...@hamburg.de) wrote:
 
  I’m a cordova developer.
 
  The idea to move the plugins to npm was a very bad one. No professional
  description, no professional searching.
 
  From a developer view, there is a need to have an overview off all
 plugins
  - just for inspiration There is a need to have a filter for platforms,
 the
  maintainer, last update, … and the most important and complicated one: Is
  the plugin checked, checked for platform, checked for version?
 
 
  Have you ever tried to bring a three wheel selector in a cordova
  application? That is a great job. Sorry for posting a screenshot, but
 this
  simple wheeler took me one week for working on iOS, Android and Windows.
 
  I tried every plugin, every modification of every plugin, I split the
  platforms … in the end I used mobiscroll and rewrote it for my needs.
 Just
  for selecting a timespan.
 
 
 
  Cordova is great, the most important job for the future is: Let give the
  people the power of cordova by good plugins.
 
 
  Jörg
 
 
 
 
 
 
 --
 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

Re: Best place to browse plugins

[Brian LeRoux]

go for it!

https://docs.npmjs.com/misc/coding-style

On Mon, Jun 1, 2015 at 1:18 PM, Raymond Camden raymondcam...@gmail.com
wrote:

 Is there any objection then to me doing some rewrites, and if so,
 anyone know offhand the style npm is using?

 On Mon, Jun 1, 2015 at 2:35 PM, Brian LeRoux b...@brian.io wrote:
  Ray: you have commit rights. =)
 
  On Mon, Jun 1, 2015 at 2:41 PM, Raymond Camden raymondcam...@gmail.com
  wrote:
 
  Do we have a rough idea of how soon we will see the improvements on the
 NPM
  side? If it is 1-2 weeks, then I don't think it is a huge big deal, but
 if
  longer than that I think we have a problem with our uses. Right now
 there
  are *no* docs if they follow the links from docs.cordova.io. We all
 know
  where the docs can be found, and I blogged on it too, but for new users
  this is not ideal, and is pretty critical I think.
 
  Query - if the issue now is that the Markdown used by core plugins
 doesn't
  match the Markdown supported by npm, instead of waiting for npm to fix
 it,
  couldn't we just do the manual grunt work ourselves? I'd happily try to
 hit
  one of the files myself if so.
 
  On Mon, Jun 1, 2015 at 1:20 PM, Kerri Shotts kerrisho...@gmail.com
  wrote:
 
   Jörg,
  
   I disagree: the move to NPM was a good move. It might not be perfect
 yet
   (far from it), but NPM is apparently moving forward with making search
  and
   such easy. The description is an issue, yes, but that’s also being
 worked
   out (and only applies to core plugins — third party plugins should be
  just
   fine). Furthermore, it means that Cordova is no longer responsible for
   maintaining a repository, which quickly becomes nontrivial when you
 have
  a
   lot of people hitting it. NPM has far more resources in this regard
 than
   does Cordova.
  
   That said, I’m also all for implementing a plugin page like Gulp,
 Yeoman,
   etc. do, even if NPM gets better searching and the like, simply
 because,
  as
   you say, it gives an overview that can lead to inspiration. I prefer
  using
   Gulp’s list or Yeoman’s list over NPM’s site, but I’m also glad that
 NPM
  is
   being used to manage the packages. Nearly everything else I’m doing
 is on
   NPM now anyway, so it works out well for my workflow that Cordova’s
  plugins
   are now too. (Never mind that the platforms and the CLI have been
 there
  for
   some time.)
  
   This is completely separate from your issue with “good plugins”. NPM
 or
   Cordova’s registry will make no difference to that — you’re relying
 upon
   the skills and goodwill of third party developers to make plugins for
  you,
   and they will all be of varying quality with varying documentation.
  That’s
   a problem with Gulp, Yeoman, and every other tool that allows
 plugins. As
   to verification with versions and platforms, that’s always going to
 be up
   to the plugin owner, not the repository. I don’t really see any way
  around
   that as it would always be hit or miss with third party plugins.
  
  
  
  
   On May 30, 2015 at 4:49:08 PM, Joerg Holz (h...@hamburg.de) wrote:
  
   I’m a cordova developer.
  
   The idea to move the plugins to npm was a very bad one. No
 professional
   description, no professional searching.
  
   From a developer view, there is a need to have an overview off all
  plugins
   - just for inspiration There is a need to have a filter for platforms,
  the
   maintainer, last update, … and the most important and complicated
 one: Is
   the plugin checked, checked for platform, checked for version?
  
  
   Have you ever tried to bring a three wheel selector in a cordova
   application? That is a great job. Sorry for posting a screenshot, but
  this
   simple wheeler took me one week for working on iOS, Android and
 Windows.
  
   I tried every plugin, every modification of every plugin, I split the
   platforms … in the end I used mobiscroll and rewrote it for my needs.
  Just
   for selecting a timespan.
  
  
  
   Cordova is great, the most important job for the future is: Let give
 the
   people the power of cordova by good plugins.
  
  
   Jörg
  
  
  
  
  
  
  --
 
 ===
  Raymond Camden, Developer Advocate for MobileFirst at IBM
 
  Email : raymondcam...@gmail.com
  Blog : www.raymondcamden.com
  Twitter: raymondcamden
 



 --
 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Building cordova.js on first build

[Brian LeRoux]

+1

On Thu, May 28, 2015 at 6:32 PM, Steven Gill stevengil...@gmail.com wrote:

 Right now, only the --browserify way does cordova.js generation in the cli.
 --browserify is currently designed to work with the CLI. I don't think it
 is worth it to add cordova.js generation functionality to the create
 scripts for now.

 Recently, I added platforms as devDependencies to cordova.js. So we do have
 two places where platforms are pinned (platformsConfig.json for cordova-lib
 and package.json for cordova.js). Since they are devDependencies, they
 aren't double pinned as they won't be installed when cordova-lib uses its
 cordova.js dependency.

 The platform dependencies for cordova.js are being used when generating
 cordova.js (non browserify) for each platform. It grabs the platform
 specific code from the dependencies. This generation is usually done when
 we are releasing a platform and want to generate a new cordova.js file
 which is used in the non-browserify workflow. When using the browserify
 workflow, those platform dependencies aren't used as the platform specific
 files (exec.js, platform.js) are moved into
 CORDOVAPROJECT/platform/PLATFORM/platform_www and are used when building
 the browserified cordova.js file.

 Since the non-browserify cordova.js is static, we don't actually need to do
 runtime generation for that file. I think Murat's usecase is rare and only
 will arise for cordova commiters who are changing platform specific js
 files. Once a new cordova.js file is generated, might as well commit it to
 master for the platform so others get the benefit of the updated js file
 instead of waiting for the next release cycle.

 Adding a command to coho to streamline this process is probably the way to
 go I'm thinking.




 On Wed, May 27, 2015 at 7:55 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Certainly would be nice to have the create scripts generate cordova.js in
  the same way CLI does. Maybe have the create script call into cordova-js?
 
  Would it make sense in this case to have platforms depend on cordova-js,
  rather than the other way around?
 
  Having cordova-js depend on platforms means:
  - we have pinned versions of platforms in cordova-lib
  - we have pinned versions of platforms in cordova-js
  - cordova-lib depends on cordova-js, meaning platforms are double-pinned?
 
  Is it possible that the pinned versions could get out of sync? Seems
  possible...
 
  I think there's probably two ways that we can simplify the dependencies:
  1. Have platforms depend on cordova-js, and have their create script know
  how to generate a cordova.js
  2. Have platforms' create script require a --path-to-cordova-js flag.
 
  We could actually do both, since in CLI we don't download package
  dependencies when adding downloading platform packages.
 
  On Tue, May 26, 2015 at 9:14 PM, Murat Sutunc mura...@microsoft.com
  wrote:
 
   I think this would be a valuable addition to coho.
  
   +1
  
   -Original Message-
   From: Steven Gill [mailto:stevengil...@gmail.com]
   Sent: Tuesday, May 26, 2015 5:40 PM
   To: dev@cordova.apache.org
   Subject: Re: Building cordova.js on first build
  
   npm linking is suggested when testing platform specific JS changes.
  
   cordova-coho's prepare-release-branch command will generate cordova.js
  and
   move it over to the platform, as well as other things, when doing a
   release. It might be worth breaking out the generating and moving JS
 part
   of that step in coho to make that command standalone so platform
  developers
   could do cordova-coho update-js -r windows to generate + copy
 cordova.js
   into cordova-windows (sibling to cordova-coho).
  
  
  
  
  
   On Tue, May 26, 2015 at 5:25 PM, Murat Sutunc mura...@microsoft.com
   wrote:
  
Thanks Steven for clarifying this for me.
   
For now I'll update the www\cordova.js manually for the windows
  platform.
Windows cordova.js is outdated and I'm hitting a bug.
   
Personally, I'm +1 with auto generating cordova.js but it's not as
easy as I originally thought because of the dependencies.
   
Currently, updating cordova.js is also not so trivial. We have a
folder structure like this:
   
Cordova Project
├─┬ cordova-js @ Dev (local) Version
│ └── cordova-windows @ NPM Version
└── cordova-windows @ Dev (local) Version
   
For platform developers the easiest workflow is to npm-link
cordova-js\cordova-windows to cordova-windows. Once linked you have
 to
grunt compile cordova-js and manually move file over cordova-windows.
   
On second thought, regenerating cordova.js from cordova-cli is not a
great idea. For browserify workflow it makes a lot of sense because
 we
don't know which plugins the user has but otherwise the file is
 static.
   
-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Tuesday, May 26, 2015 5:10 PM
To: dev@cordova.apache.org
Subject: Re: Building 

Re: [DISCUSS] Should pinned platforms allow for patch updates?

[Brian LeRoux]

I think we should experiment but I'd like to throw a strong caution to this
line of thinking.

Most of the issues in dependency hell are due to transient effects. Module
A updates but is unaware of Semver or mistakenly creates a side effect. Now
two people with the same version of Cordova have different experiences. One
potentially bad. If we pin versions the modules will be the same for
everyone everywhere.

Sometimes the functional crowd calls this idempotence. [1] I call it sanity
as ultimately release version tagging is a tool for issue tracking. If we
have issues that sometimes appear and sometimes do not we will have a
quality problem.

Lets run the experiment, but if even one issue comes up due to transient
modules I will be bringing this thread back up!

[1] http://en.wikipedia.org/wiki/Idempotence

On Fri, May 22, 2015 at 5:24 PM, Steven Gill stevengil...@gmail.com wrote:

 I'm okay with accepting patch changes without upgrading the tooling for
 now. If it works well and once we have more extensive testing in place, we
 can swap to accepting minor changes.

 -Steve

 On Fri, May 22, 2015 at 2:21 PM, Tim Barham tim.bar...@microsoft.com
 wrote:

  It's been a while since we discussed this, and I'd like to implement the
  change. I'd like to get some consensus on whether we should go with
  accepting patch changes only ('~1.2.3') or accepting minor version
 changes
  ('^1.2.3'). Should we go with patch changes only for now, and see how
  things go? I wonder how good we will be at maintaining backward
  compatibility of minor version changes :).
 
  -Original Message-
  From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
  Sent: Tuesday, May 12, 2015 4:31 PM
  To: dev@cordova.apache.org
  Subject: RE: [DISCUSS] Should pinned platforms allow for patch updates?
 
   For platform releases, we would have to test it with the oldest version
  of the CLI that could potentially pull it down.
 
  This one worries me a bit in terms of the testing burden and the version
  matrix that we will need to support.
 
  Totally in favor of having patch versions be available right away without
  requiring a tools release.
 
  Thanks,
  Nikhil
 
 
  -Original Message-
  From: Shazron [mailto:shaz...@gmail.com]
  Sent: Tuesday, May 12, 2015 3:38 PM
  To: dev@cordova.apache.org
  Subject: Re: [DISCUSS] Should pinned platforms allow for patch updates?
 
  +1 on loosening the grip on platform pinning
 
  On Tue, May 12, 2015 at 3:21 PM, Steven Gill stevengil...@gmail.com
  wrote:
   I am totally on board with --save flag saving '^1.2.3' in config.xml
   since it mimics the behavior of npm --save. No need to change anything.
  
   The more I think about it, the more I think we should loosen our grips
   on platform pinning. As long as we are being semver compliant for all
   of our platforms, we shouldn't run into issues.
  
   I like the idea of changing our pins to `^1.2.3` so it respects major
  only.
   It would grab the newest released version of the platform with the
   same major. This would only impact new projects or projects that are
   adding a platform for the first time. Existing projects would still
   have to cordova platform rm PLATFORM and cordova platform add PLATFORM
   to get the latest platform.
  
   One of the reasons we originally wanted to keep pinning was so we
   could easily help users when they tell us what version of Cordova they
   are having problems with. With the ability to add whatever version of
   platforms via `cordova platform add windows@VERSION`, knowing the cli
   version doesn't give us the details we want. Users can get installed
   platform versions with `cordova platform ls`.
  
   If we make this change, we should review our fetch/cache logic to see
   if it would grab the latest if an older version exists).
  
   We seem to have a fairly good track record with newer platform
   versions working with older CLI versions. Everytime we do a tools
   release, we could update the pinned versions to the latest released
   ones/newest version cli was tested with at release time. For platform
   releases, we would have to test it with the oldest version of the CLI
   that could potentially pull it down.
  
   What do others think?
  
  
  
  
  
  
   On Tue, May 12, 2015 at 6:36 AM, Tim Barham tim.bar...@microsoft.com
   wrote:
  
   ?Currently our pinned platforms are all in the form 1.2.3, which I
   expect means we'll always get that exact version. Should we instead
   use the form 1.2.x to allow for patches without having to do a tools
  release?
  
  
   BTW... When you add a platform, and we use the pinned version of,
   say, '1.2.3', if you use the '--save' flag, we'll save it to
   config.xml as '^1.2.3', like npm currently doe (in other words...
   'allow any backwardly compatible version'). This means adding the
   platform later could end up with a later version (even with the minor
   version greater than 2 in this example). Perhaps we need to be
   

Re: Stepping aside

[Brian LeRoux]

what does this mean for the future of your book John? (def the best
resource out there for our community and we really appreciate the years of
work you've dedicated to the project.)

also: would love to see you at PGD!

On Sat, May 16, 2015 at 3:33 AM, John M. Wargo jwarg...@gmail.com wrote:

 All,

 SAP eliminated my position back in March, so I'm no longer involved with
 SAP's Cordova-based products. I recently started a new job at Forrester
 Research; I accepted a position as a Principal Analyst in Forrester's
 Application Development and Delivery area. In this role, I'll be focusing
 on mobile and open-source development. Because of my new role, I'll likely
 not be able to participate in the Cordova project any longer.  I'll keep
 trolling the list and help out where I can, but I'm not sure at this time
 what I'll be able to do.

 I will however see you guys at open source conferences and at PhoneGap day
 this year if possible.
 --
 John M. Wargo
 @johnwargo http://twitter.com/johnwargo
 www.johnwargo.com http://www.johnwargo.com

 --

Re: Also moving to a new team

[Brian LeRoux]

really appreciate the level headed contributions to our community and code
Marcel  Staci; glad to have had the chance to work with you both!

On Thu, May 7, 2015 at 11:04 AM, Marcel Kinard cmarc...@gmail.com wrote:

 Staci Cooper and I are also moving to new positions. There already are
 backfills here coming up to speed: Karen Tran and James Dubee. You'll be
 seeing more of them here as time moves forward, joining Edna Morales.

 This has been an absolutely awesome group to work with. You're smart,
 talented, passionate, and you deliver. I can't say that I had a single bad
 experience here. I will definitely miss it, I hope our paths cross again.
 Best wishes!

 I may be tempted to dabble here in my off-hours. ;-)

 -- Marcel Kinard

  On May 5, 2015, at 11:15 AM, Andrew Grieve agri...@chromium.org wrote:
 
  As with Michal, you'll be seeing less of me around. My new full-time
  project will be on the Android port of Chrome.
 
  Just want to make it clear that us moving to new teams has nothing to do
  with a lack of faith in the project, but rather is due to needing a
 change
  of scenery and exciting new projects becoming available here.
 
  I'm super excited to see a new wave of committers joining the project!
 The
  momentum has certainly picked up:
  - Cordova-android 4.0.0 was huge
  - Plugins to npm was huge
  - Win10 and wkwebview will be massive launches as well!
 
  Great time for Cordova! (or a bad one... you know... if you're measuring
  against the goal of becoming obsolete :P)


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Apache Cordova/PhoneGap up-to-date usage stats?

[Brian LeRoux]

Hi Martin, absolute numbers are impossible given the open nature of the
project and numerous downstream distributions (phonegap, xdk, sencha,
chrome apps, etc)

That said, you can infer reasonable guesses now that much of the work is
primarily used via npm.

Some samples to get you started

http://www.npm-stats.com/~packages/cordova
http://www.npm-stats.com/~packages/cordova-ios
http://www.npm-stats.com/~packages/cordova-android

For android there have been efforts to decompile and create a best-guess. I
can't find the research but some googling should turn it up; the numbers
where roughly 10-20% of the Play Store is hybrid.


On Sat, May 2, 2015 at 10:30 AM, Martin Georgiev mgeorg...@utexas.edu
wrote:

 Hello Apache Cordova!

 Are there any up-to-date stats concerning:

 (1) how many times each version of the framework has been downloaded?

 (2) how many Android apps are built on top of the framework (across all
 versions)?

 (3) how many Android apps are built on top of each version of the
 framework?

 Thanks!

 Best,
  Martin

Re: Scoped package names for npm?

[Brian LeRoux]

the npm team has granted us the cordova org/scope when/if we're ready for
it.

On Tue, Apr 21, 2015 at 8:37 AM, Michal Mocny mmo...@chromium.org wrote:

 Okay fair enough.  I was hoping that with the lack of tools release to
 stable, we can rename without affecting end users *right now*, but not
 *soon*.

 If we never want to use scopes, fair enough.  If we ever do, it will only
 get more difficult.

 -Michal

 On Tue, Apr 21, 2015 at 11:04 AM, Andrew Grieve agri...@chromium.org
 wrote:

  Given the state of some of our plugins, dropping the distinguishing
  namespace might be a good thing :P
 
  On Tue, Apr 21, 2015 at 8:45 AM, Horn, Julian C julian.c.h...@intel.com
 
  wrote:
 
   I am also against another rename.  These name changes are very costly
 and
   disruptive.
  
   There is code in several places that assumes that you can enumerate the
   plugins selected by a project by enumerating the subdirectories of
  plugins.
   If you allow a plugin root folder to be more than a single directory,
   like @cordova/plugin-device then you break that code.
  
   Also, please remember that when you rename a plugins, you require
 people
   to update every dependency tag that refers to that plugin, unless you
   want to rely on the rename machinery forever.
  
   Julian
  
   -Original Message-
   From: Steven Gill [mailto:stevengil...@gmail.com]
   Sent: Monday, April 20, 2015 9:42 PM
   To: dev@cordova.apache.org
   Subject: Re: Scoped package names for npm?
  
   I also like scoped packages but am against another rename. Haha.
  
   I know organizations are coming soon so we will be able to create the
   Cordova organization and I believe scope packages that way. Add PMC
  members
   to the organization to be able to publish instead of relying on a
 Cordova
   npm user account.
  
   Lets wait and see how it goes.
   On Apr 20, 2015 2:29 PM, Jesse purplecabb...@gmail.com wrote:
  
re: the scoped package id, I like it, but not sure we want to change
them again ... and how much of our existing world will it break. Can
we install an '@' id currently on all platforms? It will result in a
www/plugins/@cordova/plugin-device/ folder right now, won't it?
   
re: other questions
Personally, I would rather see only committers able to publish to our
scope (assuming we go that way), just like we wanted to prevent non
committers from using org.apache.cordova namespace.
   
I considered 'cordova plugin add device' awhile back, I was going to
do it directly in plugman, but I decided against it. Currently it
would mean a 3rd attempt to find the plugin over http; 1) cpr, 2)
 npm,
3)munge name and go back to npm By this time, I think I would just
 ask
the user what they really want.
We could also do this via cordova-registry-mapper aliases.
   
   
   
@purplecabbage
risingj.com
   
On Mon, Apr 20, 2015 at 2:13 PM, Parashuram N (MS OPEN TECH) 
panar...@microsoft.com wrote:
   
 Scopes are like namespaces. In the reverse domain name world,
 org.apache.cordova was considered a namespace, right ?

 We did not want non core packages to publish to that namespace, so
 does the same argument apply ?

 Alternatively, we can think of scope as packages that apply to a
 particular environment - for example, all cordova packages would be
 @cordova scope.

 -Original Message-
 From: Michal Mocny [mailto:mmo...@google.com]
 Sent: Monday, April 20, 2015 2:03 PM
 To: dev
 Subject: Re: Scoped package names for npm?

 Other questions to answer:
 - Can 3rd-parties publish to this scope?
   - Do we want them to?
 - Do we want to default to @cordova scope if none is provided, such
 that you could do `cordova plugin add device`?

 -Michal


 On Mon, Apr 20, 2015 at 5:00 PM, Michal Mocny mmo...@google.com
   wrote:

  https://docs.npmjs.com/getting-started/scoped-packages
 
  Should we be @cordova/plugin-device instead of
  cordova-plugin-device?
 
  -Michal
 

   
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 

Re: Android 4.0 Blog Post

[Brian LeRoux]

from a fictional blog post I should write: 3 ways to bulletproof your
network

if you want to ensure your app only talks to domains you specify then:

1. do not include 3rd party scripts (or if you do make sure you trust them
and maybe keep an eye out for document.write!)
2. use ssl for all your http traffic
3. only talk to external services through a proxy you run (and auth)



On Wed, Apr 15, 2015 at 1:14 PM, Ian Clelland iclell...@chromium.org
wrote:

 On Wed, Apr 15, 2015 at 1:47 PM, Treggiari, Leo leo.treggi...@intel.com
 wrote:

  If anyone has the time to educate me, then please pardon my ignorance.
 
  Then you're suggesting that if I'm writing a cross-platform app, I stick
  with
  the legacy whitelist plugin until all of the platforms I care about
 support
  new whitelisting?  Or they already do support the new whitelisting?
 

 Most platforms *do not* support the new whitelisting. As of right now, it's
 Android 4.0.0, and iOS (4.0.x development branch).

 If you're building a cross-platform app, there are a couple of options, but
 they all come down to the fact that you need to use the old syntax for any
 platforms other than Android.


 1. Install the legacy plugin, and use the same syntax for everything
 (easiest)

 2. Install the new whitelist plugin, and have separate config.xml files for
 each platform. This may or may not be feasible, depending on your build
 system. You'll probably have to swap the config file out between builds of
 different platforms (I can't remember off-hand if there's any syntax in
 config.xml to have platform-dependent sections, but that would make this
 easier.)

 3. Install the new whitelist plugin, and use *both* syntaxes in config.xml.
 The new plugin uses access tags for network requests, but not for
 navigation, so you'd have to include allow-navigation tags as well, if
 you have more than a single-page-app. You can include both kinds of tags,
 though, and the platforms will happily just pick out the ones they
 understand.


  Thanks,
  Leo
 
  -Original Message-
  From: Joe Bowser [mailto:bows...@gmail.com]
  Sent: Wednesday, April 15, 2015 10:42 AM
  To: dev@cordova.apache.org
  Subject: Re: Android 4.0 Blog Post
 
  Isn't this why the Legacy Whitelist plugin exists?
 
  On Wed, Apr 15, 2015 at 10:40 AM Treggiari, Leo leo.treggi...@intel.com
 
  wrote:
 
   I have a question.  With the new whitelist support in Android, does
 that
   mean if I'm writing a cross-platform app, do I need to deal with
   whitelisting differently in Android and other platforms (at least until
  the
   other platforms 'catch up')?  If not, thanks.  If so, what would be the
   best way to handle the differences - perhaps using the merges
  functionality?
  
   Thanks,
   Leo
  
   -Original Message-
   From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
 Andrew
   Grieve
   Sent: Wednesday, April 15, 2015 10:18 AM
   To: dev
   Subject: Android 4.0 Blog Post
  
   The 4.0 release is posted to npm, and I've updated the blog post to
 work
   without the need for a tools release:
  
   I'd like to publish the blog post without waiting for a CLI release:
   - I've updated the post to use plugins-from-git so it works without new
  CLI
   - I've mentioned those can just wait for tools if they like
   - This should give us some early adopter feedback in case there's a
 need
   for a 4.0.1
  
  
  
 
 https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md
  
   Any objections?
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
 

Re: [Vote] 4.0.0 Android Release

[Brian LeRoux]

+1

On Tue, Apr 14, 2015, 1:07 PM Joe Bowser bows...@gmail.com wrote:

 +1

 - verified archive
 - ran mobile-spec
 - audited headers.

 On Tue, Apr 14, 2015 at 9:56 AM Andrew Grieve agri...@chromium.org
 wrote:

  I don't think we need to re-start since no one's -'ve voted, and nothing
  would be different. Feel free to start voting! :)
 
  On Tue, Apr 14, 2015 at 10:36 AM, Joe Bowser bows...@gmail.com wrote:
 
   So...since nobody voted on this thread, I think it's safe to say the
 vote
   failed.  We should probably re-start this soon.
  
   On Thu, Apr 9, 2015 at 11:04 AM Treggiari, Leo 
 leo.treggi...@intel.com
   wrote:
  
Did the DISCUSS thread have a pointer to the release notes about
   whitelist
support?
Sorry that I missed that.
   
Leo
   
-Original Message-
From: Shazron [mailto:shaz...@gmail.com]
Sent: Thursday, April 09, 2015 11:00 AM
To: dev@cordova.apache.org
Subject: Re: [Vote] 4.0.0 Android Release
   
Why is this on the Vote thread? please take it to the Discuss thread.
   
On Thursday, April 9, 2015, Treggiari, Leo leo.treggi...@intel.com
wrote:
   
 Another question, based upon my understanding, which must be wrong!

 The 4.0.0 Android Release will require the cordova-plugin-whitelist
  in
 order
 to get a whitelist implemented correctly.

 Given its name (dash-style) it is only available as an node
  component.

 The is no released CLI that knows how to fetch from npm?
 Or does 4.3, even though I don't see it in the release notes?
 Even so, there are many previous CLI releases which will not work?

 It would be good for the release notes to explain the situation.

 Leo

 -Original Message-
 From: Treggiari, Leo [mailto:leo.treggi...@intel.com
 javascript:;]
 Sent: Thursday, April 09, 2015 10:27 AM
 To: dev@cordova.apache.org javascript:;
 Subject: RE: [Vote] 4.0.0 Android Release

 Do the whitelist changes mean that current access origin entries
 in a
 config.xml file will be ignored the next time that a developer
 builds
 their project?  If so, that will certainly surprise some
 developers.

 Or does this just impact newly created projects?

 Thanks,
 Leo

 -Original Message-
 From: mmo...@google.com javascript:; [mailto:mmo...@google.com
 javascript:;] On Behalf Of Michal Mocny
 Sent: Thursday, April 09, 2015 9:54 AM
 To: dev
 Subject: Re: [Vote] 4.0.0 Android Release

 PR for Blogpost changes, hopefully making it a bit more obvious
 what
   the
 whitelist changes are:
 https://github.com/cordova/apache-blog-posts/pull/35

 Possibly we want to link to a more in-depth guide and remove some
 of
  my
 notes (i.e. specifically what needs adding, which config.xml should
   look
 like).

 Question: some of the plugin links are to github, some to npm.
  Should
   we
 document how to add these plugins using the new npm plugin name
  format?

 On Thu, Apr 9, 2015 at 12:15 PM, Andrew Grieve 
 agri...@chromium.org
 javascript:; wrote:

  Please review and vote on this 4.0.0 Android Release.
 
  Release issue: https://issues.apache.org/jira/browse/CB-8833
 
  Repos ready to be released have been published to dist/dev:
  https://dist.apache.org/repos/dist/dev/cordova/CB-8833
 
  The package was published from its corresponding git tag:
  cordova-android: 4.0.0 (f224b1f2d4)
 
  Note that you can test it out via:
 
  cordova platform add
https://github.com/apache/cordova-android#4.0.0
 
  Blog post to review is here:
 
 
 
 

   
  
 
 https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md
 
  Upon a successful vote I will upload the archive to dist/,
 publish
  it
to
  NPM, and post the corresponding blog post.
 
  Voting guidelines:
 

   
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 48 hours.
 
  I vote +1:
  * Ran coho audit-license-headers over the relevant repos
  * Ran coho check-license to ensure all dependencies and
   subdependencies
  have Apache-compatible licenses
  * Ran mobilespec and only expected failures were happening
  * Verified contents of archive
 

   
  B�CB�
 � [��X��ܚX�K  K[XZ[
 �  ]�][��X��ܚX�P �ܙ ݘK�\ X� K�ܙ�B��܈ Y  ] [ۘ[  ��[X[� �  K[XZ[
 �  ]�Z [   �ܙ ݘK�\ X� K�ܙ�B

   
  
 

Re: Github, again.

[Brian LeRoux]

Alas, no. Vote threads MUST be an email. Our original interpretation:
tagging a release by a PMC 'platform lead' === Vote… which, some may
recall, the board did not take kindly.

Moving from code to conversation def has slowed the project cadence down.
Our last major release was July 2013. There was a significant stall in
adoption but that seems to have recovered and really put wind back in the
sails for downstreams I can measure like PhoneGap. Maybe that is ok. Def a
great conversation piece.


On Mon, Apr 13, 2015 at 3:55 PM, Josh Soref jso...@blackberry.com wrote:

 Tony wrote:
  FWIW, I don¹t think that Cordova JIRA is horrible.
  We use JIRA at Intel and have had a lot of intermittent performance
  problems that were mostly resolved with a recent version update.
  It seems like a lot of effort has been invested in the Cordova JIRA and
 it
  seems (to me) like it would be a shame to move away from it.
  I¹ll leave it at that and comment on your other thread Michal.

 Fwiw, we use JIRA at work, and I hate that JIRA much more than I hate
 Apache's JIRA.

 We also have a GitHub tracker that we use for WebWorks.
 I'm not a big fan of it, but the simplicity is a nice thing relative to all
 of the mandatory knobs in my least favorite JIRA.

 GitHub's linking features are vaguely nice.

 Note: in general, I'm a proponent of being able to review the history of
 code and being able to understand why a change was made.
 Traditionally, that involves looking at a bug tracker and reading the bug.

 However, neither JIRAs I've mentioned today are used that way, often
 they're
 at best Process Shepherds, and often they're just full of noise.

 I don't need a Process Shepherd, and if I have to have one, I'd rather it
 be
 Pull Requests.

 A funny thing to consider in this area:

 Instead of having a vote thread which people can email -- and which
 frequently spirals out of control.
 We could have a Vote RC file, and people could pull request their +1s.

 No one in their right mind would try to add a long comment into such a vote
 file.

 But, we could have a discuss thread. And we could receive emails about pull
 requests for the +1s.

 Such a thing could be trackable, in a meaningful way...
 And your commit message / pull request for a +1 could explain what you
 tested.

  On the other hand (and this is the real point I wanted to make), the wiki
  is horrible.

  It is barely useable and it¹s poor performance is a major de-motivator
  when it comes to editing it.

 Its performance definitely isn't a plus.

 The process of managing accounts is a bumber.

 I'd certainly favor a pull request model (which GitHub pages would give
 me).

  There are important documents and information that only exist on the
 wiki!
  In one of the other threads, Carlos suggested using Github wiki - it
 seems
  like this would be a great change to me if it is possible.
  From my perspective, this would be a far more valuable change than moving
  from JIRA to Github Issues.
  Just wanted to raise it since you seem to be interested in spinning some
  of these topics off into dedicated discussion threadsŠ

 I've seen some projects try using GitHub pages, and I haven't seen many
 where it works particularly well.
 OTOH, I haven't seen *anything* that works particularly well.

Re: Tools for Cordova Commits Presentation Slides

[Brian LeRoux]

 

On Mon, Apr 13, 2015 at 4:36 PM, Shazron shaz...@gmail.com wrote:

 Yeah http 403. Andrew, if you don't mind maybe post a file link? Or
 slideshare or something :)  -- how am I doing

 On Mon, Apr 13, 2015 at 2:31 PM, Homer, Tony tony.ho...@intel.com wrote:
  First, thanks for sharing this!
  Second, I tried to download so I could read offline, but I guess the
  permissions don¹t allow it? It seemed to silently fail.  If that is
  intended, no problem.
  Thanks again, reading online now.
 
  Tony
 
  On 4/13/15, 4:58 PM, Jesse purplecabb...@gmail.com wrote:
 
 And I almost forgot the last bit I learnt from your slides ... ;)
 smileys!
 
 
 @purplecabbage
 risingj.com
 
 On Mon, Apr 13, 2015 at 1:53 PM, Jesse purplecabb...@gmail.com wrote:
 
  I got a little confused by slide #54/55
  My name is circled, but I didn't merge that pull request, I commented
 on
  the next one #172 ... of course, if I had your narration, I would have
 been
  fine.
 
  Thanks for sharing this!
  Were the talks recorded?
 
  @purplecabbage
  risingj.com
 
  On Mon, Apr 13, 2015 at 1:31 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
  Great lessons learned!
 
  On Mon, Apr 13, 2015 at 4:29 PM, Murat Sutunc mura...@microsoft.com
  wrote:
 
   Looks pretty good to me!
  
   -Original Message-
   From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
  Andrew
   Grieve
   Sent: Monday, April 13, 2015 1:14 PM
   To: dev
   Subject: Tools for Cordova Commits Presentation Slides
  
   Created the slides to be readable without me talking over them in
 hopes
  to
   be a form of documentation for the project :)
  
   Mainly:
   - how to use some of coho,
   - how to do a pull request
   - picture guides to visual debugging for node, android, ios
  
   http://goo.gl/ciGnaR
  
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Does Cordova have a problem making developers happy?

[Brian LeRoux]

Oh we tried to help. And yes we asked. We were very rudely treated. On and
off list. (Or, I was anyhow.)

I'm all for being positive, and I generally am, but I am also not
interested in perpetuating a revisionist narrative about how apache has
been great to work with. I have always maintained a professional dialogue
even when receiving personal attacks and threats. The records show that and
I can sleep at night.

Can that change? I continue to hope so. Not even a month ago I was harassed
by a member. I'll be at apachecon to discuss f2f since email had proven to
be a terrible medium so far.

On Thu, Apr 9, 2015, 12:47 PM Andrew Grieve agri...@chromium.org wrote:

 Apache provides a lot of benefit. I don't want elaborate right now, but I
 will promise to post back with some formulated thoughts a bit later (some
 of this I'm prepping for my ApacheCon talk, so I need to do it anyways).

 Joe - Please please *please* do not write emails that are not constructive.
 If you want to be negative, don't hit the send button. If not for the sake
 of others, for the sake of yourself - saying negative things about others
 almost always ends up making you look worse than those you are being
 negative towards.

 Another angle:
 Even if you are convinced that you're right, and even though your views are
 your own (although statements like Or we could just leave the ASF make it
 sound like you are representing more than that), your tone often just makes
 people want to run away rather than engage. Would you want to contribute to
 a project that is full of smileys and encouragement, or one where people
 are negative and abrasive? It really goes a long way to keep the email tone
 positive even when you disagree.

 Since I've been on this project, I've felt that non-Cordova Apache'ers (we
 are apache'ers too remember) have been constructive and helpful:
 - We want a VM. Mike Billau reached out, and INFRA helped us set one up.
 - We want to do BuildBot. Infra helped get us going on their shared
 instance.
 - We want to use git. So do other projects, and it has been a collaboration
 between Infra and other projects that made it happen (we complained, but
 didn't do the work to make it possible).
 - We want to try reviewboard - Infra got us going in no time (although we
 decided not to stick with it).

 Why can we not use Github issues?
 - It's certainly *not* the case that Apache hates github.
 - Has anyone even thought to ask? Maybe it's just a conversation that
 hasn't happened yet.
 - It's important that Apache projects host their own data, but do issue
 trackers count as data?
 - Sounds like a *great* discussion to have.
 - d...@community.apache.org would be a great place to start, since that's
 meant for cross-project discussion.


 On Thu, Apr 9, 2015 at 1:53 PM, Joe Bowser bows...@gmail.com wrote:

  On Thu, Apr 9, 2015 at 10:35 AM Ross Gardler (MS OPEN TECH) 
  ross.gard...@microsoft.com wrote:
 
   Firstly, don't call someone a liar simply because you disagree, it is
   offensive and exactly the kind of behavior I am referring to (and why
 *I*
   dread ever posting to this list, shame that question wasn't in the
 Stack
   Overflow survey).
  
  
  Did you intend this to go to me or the list, because based on the tone
  you're using, I can't be sure.  If you're looking to make a personal
 attack
  on me publicly, then fine, go ahead.  On this list, these comments only
  reflect my own personal views.  It's clear that people don't agree with
 me,
  because we're still here.
 
  Joe
 
  Ross
  
  
   -Original Message-
   From: Joe Bowser [mailto:bows...@gmail.com]
   Sent: Thursday, April 9, 2015 9:28 AM
   To: dev@cordova.apache.org
   Subject: Re: Does Cordova have a problem making developers happy?
  
   On Thu, Apr 9, 2015 at 9:13 AM Ross Gardler (MS OPEN TECH) 
   ross.gard...@microsoft.com wrote:
  
   
There are no powers that be. Bring a member brings no additional
influence. What matters around here is constructive contributions and
participation.
   
   
   That's a lie that we've seen played out numerous times.  There are
  clearly
   people who bully people in project to fall into line. We've had to
 fight
   the ASF every single time we wanted to do anything with this project,
 and
   I'm expecting us to fight the ASF again until we eventually leave.
  
  
To be constructive one needs to understand why things are the way
 they
are and, if they don't fit, one needs to work with people to propose
changes that work.
   
   
   Or we could just leave the ASF and find a different foundation whose
  rules
   aren't as rigid.  That could work too.
  
  
Historically this project has had real difficulty doing just that.
Instead it has focused on negativity and mud slinging (there are some
individuals who certainly do not fit into this category, but their
voices are usually drowned out.
   
   
   I'm very proud of my record of fighting the ASF.  I regret that we
  

Re: Does Cordova have a problem making developers happy?

[Brian LeRoux]

I should note not all the membership is the same. We do have many
supporters at the ASF and from a high level the organization is incredible
and important. I don't regret our choice to move here and do think things
are changing for the better. (Albeit too slowly for my liking.) Consensus
is hard. The ASF predates software as a service for developer tools and
most of the policy was (until recently) ambiguous if not outright
undocumented. Change is happening so I'm opting to be optimistic. Most ppl
that still write code recognize the importance of continuous delivery and
release automation. Some them realize that those things are not existential
threats even. We'll get there.

On Thu, Apr 9, 2015, 12:56 PM Brian LeRoux b...@brian.io wrote:

 Oh we tried to help. And yes we asked. We were very rudely treated. On and
 off list. (Or, I was anyhow.)

 I'm all for being positive, and I generally am, but I am also not
 interested in perpetuating a revisionist narrative about how apache has
 been great to work with. I have always maintained a professional dialogue
 even when receiving personal attacks and threats. The records show that and
 I can sleep at night.

 Can that change? I continue to hope so. Not even a month ago I was
 harassed by a member. I'll be at apachecon to discuss f2f since email had
 proven to be a terrible medium so far.

 On Thu, Apr 9, 2015, 12:47 PM Andrew Grieve agri...@chromium.org wrote:

 Apache provides a lot of benefit. I don't want elaborate right now, but I
 will promise to post back with some formulated thoughts a bit later (some
 of this I'm prepping for my ApacheCon talk, so I need to do it anyways).

 Joe - Please please *please* do not write emails that are not
 constructive.
 If you want to be negative, don't hit the send button. If not for the sake
 of others, for the sake of yourself - saying negative things about others
 almost always ends up making you look worse than those you are being
 negative towards.

 Another angle:
 Even if you are convinced that you're right, and even though your views
 are
 your own (although statements like Or we could just leave the ASF make
 it
 sound like you are representing more than that), your tone often just
 makes
 people want to run away rather than engage. Would you want to contribute
 to
 a project that is full of smileys and encouragement, or one where people
 are negative and abrasive? It really goes a long way to keep the email
 tone
 positive even when you disagree.

 Since I've been on this project, I've felt that non-Cordova Apache'ers (we
 are apache'ers too remember) have been constructive and helpful:
 - We want a VM. Mike Billau reached out, and INFRA helped us set one up.
 - We want to do BuildBot. Infra helped get us going on their shared
 instance.
 - We want to use git. So do other projects, and it has been a
 collaboration
 between Infra and other projects that made it happen (we complained, but
 didn't do the work to make it possible).
 - We want to try reviewboard - Infra got us going in no time (although we
 decided not to stick with it).

 Why can we not use Github issues?
 - It's certainly *not* the case that Apache hates github.
 - Has anyone even thought to ask? Maybe it's just a conversation that
 hasn't happened yet.
 - It's important that Apache projects host their own data, but do issue
 trackers count as data?
 - Sounds like a *great* discussion to have.
 - d...@community.apache.org would be a great place to start, since that's
 meant for cross-project discussion.


 On Thu, Apr 9, 2015 at 1:53 PM, Joe Bowser bows...@gmail.com wrote:

  On Thu, Apr 9, 2015 at 10:35 AM Ross Gardler (MS OPEN TECH) 
  ross.gard...@microsoft.com wrote:
 
   Firstly, don't call someone a liar simply because you disagree, it is
   offensive and exactly the kind of behavior I am referring to (and why
 *I*
   dread ever posting to this list, shame that question wasn't in the
 Stack
   Overflow survey).
  
  
  Did you intend this to go to me or the list, because based on the tone
  you're using, I can't be sure.  If you're looking to make a personal
 attack
  on me publicly, then fine, go ahead.  On this list, these comments only
  reflect my own personal views.  It's clear that people don't agree with
 me,
  because we're still here.
 
  Joe
 
  Ross
  
  
   -Original Message-
   From: Joe Bowser [mailto:bows...@gmail.com]
   Sent: Thursday, April 9, 2015 9:28 AM
   To: dev@cordova.apache.org
   Subject: Re: Does Cordova have a problem making developers happy?
  
   On Thu, Apr 9, 2015 at 9:13 AM Ross Gardler (MS OPEN TECH) 
   ross.gard...@microsoft.com wrote:
  
   
There are no powers that be. Bring a member brings no additional
influence. What matters around here is constructive contributions
 and
participation.
   
   
   That's a lie that we've seen played out numerous times.  There are
  clearly
   people who bully people in project to fall into line. We've had to
 fight
   the ASF every single time we

Re: Platform guides update

[Brian LeRoux]

We recommend using the thing that works best for you for building apps BUT
if you are extending Cordova you'll need to run with Android Studio, Xcode
and friends. We support both.

On Tue, Apr 7, 2015 at 12:47 PM, Raymond Camden raymondcam...@gmail.com
wrote:

 Replace Eclipse example w/ Android Studio as officially recommended
 option/tool
 Do we really recommend this over CLI + your favorite editor ?

 On Tue, Apr 7, 2015 at 2:35 PM, Jesse purplecabb...@gmail.com wrote:
  +1000
 
  @purplecabbage
  risingj.com
 
  On Tue, Apr 7, 2015 at 12:31 PM, Andrew Grieve agri...@chromium.org
 wrote:
 
  These changes all sound great!
 
  On Tue, Apr 7, 2015 at 3:01 PM, Sergey Grebnov (Akvelon) 
  v-seg...@microsoft.com wrote:
 
   Hi guys, I see that some docs are outdated or not actual anymore so I
  want
   to improve this. Please let me know if someone already working on
 this or
   going to take a look. I've listed below some things I want to update,
  could
   you please review them before I stared working on this (additional
   suggestions and ideas are very welcome)
  
   iOS:
   1. Xcode 4.x-5.x
   2. Add information about ios-sim required to deploy app from
 command
   line
   3. Add information how to list available deploy targets and run
 app
  on
   specific target/device
  
   Android:
  1. Add changes in favor of replacing Ant w/ Gradle
  a. Remove Ant from requirements
  b. Replace Eclipse example w/ Android Studio as officially
   recommended option/tool
  2.  Add more details about particular Android packages/components
   required to be installed.
   Android 5.0.1 (API 21) platform SDK
   Android SDK Build-tools version 19.1.0 or higher
   Android Support Repository (Extras)
   3. Add information how to list available deploy targets and run
 app
  on
   specific target/device
  
   Windows:
   1. Remove 'To develop apps for Windows 8.0 only:'
   2. Hardware requirements to run Windows Phone emulator (Client
  Hyper-V
   and Second Level Address Translation (SLAT))
   3. Add information how to list available deploy targets and run
 app
  on
   specific target/device
  
   Thx!
   Sergey
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 



 --
 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Platform guides update

[Brian LeRoux]

I humbly submit that we want very detailed documentation to turn those
lower numbers into more involved community members. (Ideally contributing
code and docs themselves!)

On Tue, Apr 7, 2015 at 1:24 PM, Raymond Camden raymondcam...@gmail.com
wrote:

 That makes sense - I just worry that if that use case (extending
 Cordova) is 10% of the reader base than it should not (imo) be 50% of
 the docs. Btw - totally guessing at those numbers as I haven't seen
 the changes. :)

 On Tue, Apr 7, 2015 at 2:58 PM, Brian LeRoux b...@brian.io wrote:
  We recommend using the thing that works best for you for building apps
 BUT
  if you are extending Cordova you'll need to run with Android Studio,
 Xcode
  and friends. We support both.
 
  On Tue, Apr 7, 2015 at 12:47 PM, Raymond Camden raymondcam...@gmail.com
 
  wrote:
 
  Replace Eclipse example w/ Android Studio as officially recommended
  option/tool
  Do we really recommend this over CLI + your favorite editor ?
 
  On Tue, Apr 7, 2015 at 2:35 PM, Jesse purplecabb...@gmail.com wrote:
   +1000
  
   @purplecabbage
   risingj.com
  
   On Tue, Apr 7, 2015 at 12:31 PM, Andrew Grieve agri...@chromium.org
  wrote:
  
   These changes all sound great!
  
   On Tue, Apr 7, 2015 at 3:01 PM, Sergey Grebnov (Akvelon) 
   v-seg...@microsoft.com wrote:
  
Hi guys, I see that some docs are outdated or not actual anymore
 so I
   want
to improve this. Please let me know if someone already working on
  this or
going to take a look. I've listed below some things I want to
 update,
   could
you please review them before I stared working on this (additional
suggestions and ideas are very welcome)
   
iOS:
1. Xcode 4.x-5.x
2. Add information about ios-sim required to deploy app from
  command
line
3. Add information how to list available deploy targets and run
  app
   on
specific target/device
   
Android:
   1. Add changes in favor of replacing Ant w/ Gradle
   a. Remove Ant from requirements
   b. Replace Eclipse example w/ Android Studio as officially
recommended option/tool
   2.  Add more details about particular Android
 packages/components
required to be installed.
Android 5.0.1 (API 21) platform SDK
Android SDK Build-tools version 19.1.0 or higher
Android Support Repository (Extras)
3. Add information how to list available deploy targets and run
  app
   on
specific target/device
   
Windows:
1. Remove 'To develop apps for Windows 8.0 only:'
2. Hardware requirements to run Windows Phone emulator (Client
   Hyper-V
and Second Level Address Translation (SLAT))
3. Add information how to list available deploy targets and run
  app
   on
specific target/device
   
Thx!
Sergey
   
   
 -
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
   
   
  
 
 
 
  --
 
 ===
  Raymond Camden, Developer Advocate for MobileFirst at IBM
 
  Email : raymondcam...@gmail.com
  Blog : www.raymondcamden.com
  Twitter: raymondcamden
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 



 --
 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

plugins, npm, and package.json …other art

[Brian LeRoux]

both reactnative [1] and nativescript [2] treading into the territory

fleeting hope we could share work/code but probably good everyone does a
bit of homework on the topic

[1] https://github.com/facebook/react-native/issues/235
[2] https://github.com/NativeScript/NativeScript/issues/25

Re: [Android] Proposal: Deprecate/No-Op Battery Plugin

[Brian LeRoux]

I do! --
3) Recognize and Handle Offline Status

On Thu, Mar 26, 2015 at 11:09 AM, Raymond Camden raymondcam...@gmail.com
wrote:

 Do you think it fits in the Next Steps doc?

 On Thu, Mar 26, 2015 at 1:05 PM, Josh Soref jso...@blackberry.com wrote:
  I'm really hoping someone like Raymond will write something nice and
 pretty about this.
 
  That isn't my strong suite.
 
  Brian wrote:
  this! is really good advice and should make it into our guides.
 
  Thanks
 
  Josh Soref jso...@blackberry.com wrote:
 
  Andrew wrote:
   Let's just update the README to state that the battery plugin is a
  plugin
   that uses your battery :)
 
  I'm +1 on this
 
   Only half joking... probably would be minimal effort and enough to
 just
  add
   a warning about this and do nothing more.
 
  it's not a joke, old battery apis (and probably on other platforms too,
 i
  can't remember which) really are harmful.
 
  plus, it's rarely the right thing to do.
 
  app developers should really be event driven:
 
  e.g.:
  * gaining network connection to their uplink
  * having sufficient data to justify sending
  * receiving a notice (e.g. a push) that they have data to fetch
 
  and they should use some local storage cache for everything else.
 
  * they should be resilient to users reseting their devices (power cycle,
  os OTA, battery pull, device kernel panic).
  * they should be resilient to users choosing to go into airplane mode
 for
  a 10 hour flight and running out of battery before disembarking.
 
  a battery api doesn't help w/ these things. being event driven does.
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 



 --
 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] cordova-wp8 + Newtonsoft.JSON

[Brian LeRoux]

fairly certain distributing binaries isn't ok (except when it is such as
maven or open office)

=/

an email to legal-discuss is good diligence regardless

On Thu, Mar 26, 2015 at 11:27 AM, Ian Clelland iclell...@chromium.org
wrote:

 Parashuram, from the link you provided in the previous thread (
 http://www.apache.org/legal/resolved.html), it looks like only a small set
 of licenses (Category B) make binary distribution with Apache projects
 possible, and the MIT license isn't on that list.

 We should definitely get Apache legal looped into this discussion before we
 consider distributing this in binary form. I realize it's the smallest and
 easiest, and best for the users, but we have to work with the ASF.

 On Thu, Mar 26, 2015 at 2:13 PM, Parashuram N (MS OPEN TECH) 
 panar...@microsoft.com wrote:

  I think we can use option 4 - distributing DLLs of third party software
 is
  fine - we only need to ensure that it is clean from an IP perspective. I
  think 4 is the best option as you said, and we could ask the author of
 the
  library about any potential patent issues. I also think that Apache puts
  the due diligence of IP and patent responsibility on the committers
 
  -Original Message-
  From: Jesse [mailto:purplecabb...@gmail.com]
  Sent: Thursday, March 26, 2015 11:05 AM
  To: dev@cordova.apache.org
  Subject: [DISCUSS] cordova-wp8 + Newtonsoft.JSON
 
  We have several options, of varying difficulty, legal responsibility,
  risk, and technical debt.
 
  1. Redistribute Newtonsoft.JSON (NJ) source code as part of every new
  cordova-wp8 project
- it's a lot of code to add to the project, more that cordova-wp8
 itself
- we completely control our dependencies and will never fall out of
 sync
 
  2. Redistribute NJ source as part of the library and have every new
  cordova-wp8 project link to it.
- some added complexity, but technically sound, and not as wasteful
  seeming as #1
- we could have issues with dependencies if NJ included source changes
  between cordova-wp8 versions
 
  3. Redistribute NJ source, build it when cordova-wp8 is installed on the
  users machine, add the .dll to every new cordova-wp8 project.
 - same issues/benefits as #2, some added complexity
 
  4. Redistribute NJ as a pre-built dll and as part of the wp8 template.
- I like this best, but we have to dig through legal some more.
 
  5. Do some magic with nuget dependencies so VS will download it.
- lots of unknowns ( to me, others may know more )
- can only create cordova-wp8 projects when online ( Android already
 has
  this restriction )
 
  6. Redistribute NJ as a cordova-wp8  plugin and make it a dependency of
  cordova-wp8
- a little awkward, but doable
 
  7. Do nothing
- realistically wp8 should be deprecated soon, wp8.1 has much more to
  offer, and win10 is on the horizon. We could just let the sun set.
 
 
 
 
 
 
 
 
 
  @purplecabbage
  risingj.com
 

Re: ApacheCon NA, Austin, April 13-16

[Brian LeRoux]

I am!
On Fri, Mar 20, 2015 at 5:13 PM Nikhil Khandelwal nikhi...@microsoft.com
wrote:

 I'll be there. It would be great to meet others who are going.

 Thanks,
 Nikhil


 -Original Message-
 From: Anis KADRI [mailto:anis.ka...@gmail.com]
 Sent: Friday, March 20, 2015 3:04 PM
 To: dev@cordova.apache.org
 Subject: Re: ApacheCon NA, Austin, April 13-16

 Reviving this thread. Other than Andrew, Mark and Hazem. Anybody else
 going ? I plan to attend.

 On Sat, Jan 31, 2015 at 6:46 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Submitted a talk proposal:
 
  Abstract:
  The Cordova project can sometimes be hard to contribute to given the
  large number of pieces that make it up. There are a few tools that
  make it much more manageable though. In this session, Andrew will
  cover many of the tools and techniques that make developing on Cordova
  a more coherent experience.
 
 
  Going to cover git workflow, coho commands, --link and IDEs, CIs,
  Testing via windows VM.
 
 
  On Fri, Jan 9, 2015 at 11:39 AM, Joe Bowser bows...@gmail.com wrote:
 
   Is this a troll post?
  
   On Fri, Jan 9, 2015, 8:21 AM Andrew Grieve agri...@chromium.org
 wrote:
  
http://events.linuxfoundation.org//events/apachecon-north-
america/program/cfp
   
Last year we had about a days worth of Cordova talks and ran a
  hackathon
(thanks to IBM)! For me, the real value was in learning more about
   Apache,
and getting to spend time with other committers.
   
So... I still think it'd be good to do a few presentations. CFP is
open until the end of the month. Audience is mostly enterprise
types, Apache committers, and of course, ourselves. Talks on
Cordova or on Apache processes would be good (e.g. a talk on
setting up github PRs with
   Travis 
AppVeyor, hint hint).
   
Even more though, I think we should take the opportunity to do
some
  work
while co-located. There's always a lot of value in face time, and
I
  think
the venue suits it well (there were lots of hackathon-type rooms
available).
   
So, concretely - anyone want to state their intention of giving a
talk,
   or
attending? I know at least a few of us from Google are planning on
  going.
   
  
 

Re: Android JUnit Tests Now Pass

[Brian LeRoux]

I see no situation where we don't want a feature branch vetted by 1 person
before we land anything on master …short of fixing broken tests.

I assume good faith. Joe: you had a bad day and, I think, you still feel
mistrust after previous commits landing on master stalling out your work
last summer. Lets put that behind us.

Andrew pls fire a ping to the list w/ a PR for anything aiming to live on
Android master until earn Joe's trust back. And lets avoid the editorial
about motivations. We all want the same thing here: work on a kick ass open
source project that makes a difference.


On Thu, Feb 12, 2015 at 9:31 AM, Jesse purplecabb...@gmail.com wrote:

 This commit may not have warranted this discussion.
 I think we agree that large changes/commits should be on feature branches,
 and discussed before being merged.
 Let's go with that.



  On Feb 12, 2015, at 8:49 AM, Andrew Grieve agri...@chromium.org wrote:
 
  Sounds like you've been having a rough time. :( Hope you get through it.
 
  Believe me when I say I hear you loud and clear about making changes on
  feature branches. I just don't think this one fits.
  - No one (other than me) has touched the tests since September of last
  year, so it's unlikely that a change would cause merge conflicts.
  - The state of the tests show that they are not viewed as that important
  (at least not important enough for anyone other than me to have been
  working on them)
  - Anything I do to them doesn't affect shipping code. No risk.
 
  I find it hard to believe that my making changes contributes in a
  significant way to having people avoid working on Android. Perhaps being
  overly abrasive via email  JIRA would be a deterrent though...
 
 
 
 
  On Thu, Feb 12, 2015 at 11:10 AM, Joe Bowser bows...@gmail.com wrote:
 
  On Thu Feb 12 2015 at 7:44:52 AM Andrew Grieve agri...@chromium.org
  wrote:
 
  I agree that significant changes should be reviewed first. But for the
  most
  part Cordova is a review-after-commit kind of place,
 
 
  No, it's not.  Cordova is only like that because you consistently make
 it
  like that.  Constantly committing to master without any review at all
 makes
  it next to impossible for anyone else to work on the project.  You can
 tell
  that this is the case, because you own the majority of the commits over
 the
  last few months. That's not normal for a codebase this size with this
 many
  contributors.  This is why we have topic branches, and we've had this
  discussion with you numerous times about using them.  This is also why I
  write e-mails trying to get buy-in to what I want to do instead of just
  landing features straight on master that could break everything.
 
 
  and this change didn't
  touch any code that we release (strictly tests... that have been broken
  for
  a very long time), so I don't think it qualifies.
  I'll admit that the tests were a bit of the wild west.  That said, there
  was always an understanding that tests would be added to and improved
 upon
  and not removed.  Marcel and I probably wouldn't have had half the
 e-mails
  that we have had if it wasn't us arguing over whether to delete tests.
 
  I know it's frustrating to have to wait on other people, since people
 are
  human, get sick, and have to take care of others when they're sick.
 That
  said, it's equally frustrating to come back from vacation, or wake up
 from
  a nap after driving someone from the hospital and see that critical code
  that was a major issue only six months ago got accidentally removed in a
  sweeping change, along with other use cases.  That's what happened
  yesterday, and that's why I got frustrated.  If I'm having a bad day
  already, a random refactor that just gets dropped without at least a
 head's
  up beforehand makes it worse.
 
  I've been on both sides of the issue with this.  I remember getting
  extremely frustrated with Bryce when we designed CordovaWebView,
 especially
  since my design had less of a change to the code.  I thought things were
  moving too slowly, but at the end of the day we did produce something
 that
  a lot of people seem to use (at least that's what the sample repo I
 have on
  GitHub tells me, the GitHub analytics tools are all I have to go on).
 That
  said, we didn't ship that until it was mostly ready, and other than an
  awkward presentation at PhoneGap Day, it was mostly fine.  I'm glad I
  didn't just merge my crap in and just unilaterally introduce that
 feature,
  since back then we could still get away with that technically.
 
  But yeah, can we have things on feature branches if they're that big,
 and
  then wait maybe 24 hours before dropping something like that? I'm not
  talking like a simple JIRA fix, but something that large should have
 been a
  pull request or on its own branch or something.
 
 
  On Thu, Feb 12, 2015 at 4:07 AM, Jesse purplecabb...@gmail.com
 wrote:
 
  You may or may not, but I think it would be nice to let others review
  your
  (significant) 

Re: Crosswalk-powered InAppBrowser plugin

[Brian LeRoux]

could be its own thing but if it came under the actual inappbrowser that'd
be cool too

https://github.com/apache/cordova-plugin-inappbrowser


On Thu, Feb 5, 2015 at 3:25 PM, Sidney Bofah sidney.bo...@googlemail.com
wrote:

 Hi all,

 my company recently required the availability of a high-performance
 Android modal WebView (that is, Chromium-based, disposable, free of memory
 leaks, etc.) in context of a Crosswalk-based Cordova/Ionic project. My
 research had shown that the widely used InAppBrowser plugin has not made
 any progress or attempts in terms of being extended (or migrated) towards
 using the XWalkView stuff yet. However, as the container app already
 employed Cordova-Crosswalk, this seemed counterintuitive. Solutions such as
 the Cocoon WebViewPlus were too opaque.

 As a solution, i devised a version of the plugin that uses Crosswalk
 (13/Canary) as its rendering engine, with a dependency on the
 cordova-engine-crosswalk project (the host project is based on Ionic). In
 this context, it was required to migrate its legacy WebView architecture to
 Chromium. The results are promising this far, and could possibly benefit
 many Android apps using rendering-intensive, temporary webviews.

 Currently, the code lives in a private repository, but is to be open
 sourced. My questions are: Which project, branch, repo etc. would be the
 correct context for contributing?

 Cheers,
 Sidney
 --
 https://github.com/sidneys


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Review] Plugins Package.json

[Brian LeRoux]

love this, having a cordova key is a v good idea while this bakes too

On Wed, Feb 4, 2015 at 12:10 PM, Parashuram N (MS OPEN TECH) 
panar...@microsoft.com wrote:

 +1 to changing cordova-windows8 to cordova-windows.

 On 2/4/15, 12:05 PM, Jesse purplecabb...@gmail.com wrote:

 Yes, you can skip all the 'windows8' stuff and just use 'windows'.
 windows8 is legacy and slowly all plugins are being migrated to just use
 the 'windows' section in plugin.xml
 
 @purplecabbage
 risingj.com
 
 On Wed, Feb 4, 2015 at 11:36 AM, Steven Gill stevengil...@gmail.com
 wrote:
 
  I have made the changes you suggested. I like the idea of cordova parent
  key.
 
  I added cordova-windows8 as a keyword but I would like someone from
  microsoft to chime in about it. My understanding is that windows8 is
 around
  for legacy and windows is preferred. Please correct me if I'm wrong. I'd
  prefer to just list windows and cordova-windows.
 
  If anyone else has feedback on the package.json file, please share! You
 can
  view it at
 
 
 
 https://github.com/stevengill/cordova-plugin-device/blob/npmpub/package.j
 son
 
  I am working on createpackagejson command now
  https://issues.apache.org/jira/browse/CB-8416
 
  On Tue, Feb 3, 2015 at 5:29 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   From looking at it, only thought is whether we should put all of the
   non-standard fields into a cordova parent key. E.g.:
  
   {
 name: cordova-plugin-device,
 cordova: {
id: org.apache.cordova.device,
platforms: [...]
 }
   }
  
   Sounds like we need to re-write the file when publishing to CPR
 anyways,
  so
   transforming from this to what is currently expected can be done in
 that
   step.
  
   Other tidbits:
   - windows8 is missing from keywords. Intentional? (not sure if
 windows is
   now an alias?)
   - author: might just set this to Apache
  
  
   On Tue, Feb 3, 2015 at 7:50 PM, Steven Gill stevengil...@gmail.com
   wrote:
  
Please review at
   
   
  
 
 
 https://github.com/stevengill/cordova-plugin-device/blob/npmpub/package.j
 son
   
You will notice that I added cordova-PLATFORM as a keyword.
   
I have also kept the platforms tag for now. I can remove it but
 maybe
  we
can find some future use for it. We currently need it when
 publising to
   CPR
but can add/rm it during plugman publish.
   
I am going to create a createpackagejson command in plugman that
 will
   build
something like this from plugin.xml. Other plugin devs will be able
 to
   use
this command to quickly add package.json files to their plugins.
   
I will then modify plugman publish to use the createpackagejson
 command
   if
needed. Plugman publish will still have to add the contents of the
  readme
(or doc/index.md) to the package.json as well as the platforms tag
 if
  we
decide to remove it. It will also have to change the package-name
 field
   to
package-id when publishing to CPR. Once published, we can remove
 these
changes package.json.
   
If the package.json file looks good, I'm going to start adding one
 to
  all
of our plugins.
   
  
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] 3.7.0 Android Platform release

[Brian LeRoux]

+1

On Thu, Jan 22, 2015 at 10:51 AM, Sergey Grebnov (Akvelon) 
v-seg...@microsoft.com wrote:

 I vote +1
 •   Verified archives via `coho verify-archive`.
 •   Verified tags manually.
 •   Verified blank app can be created and run
 •   Ran smoke testing of mobilespec app (autotests) and compatibility
 with core plugins.
 •   Verified Release Notes.

 Thx!
 Sergey
 -Original Message-
 From: Joe Bowser [mailto:bows...@gmail.com]
 Sent: Wednesday, January 21, 2015 8:10 PM
 To: dev
 Subject: [VOTE] 3.7.0 Android Platform release

 Please review and vote on this 3.7.0 Android Platform Release.

 Release issue: https://issues.apache.org/jira/browse/CB-8335

 Repos ready to be released have been published to dist/dev:
 https://dist.apache.org/repos/dist/dev/cordova/CB-8335/

 The packages were published from their corresponding git tags:
 cordova-android: 3.7.0 (f3885692d9)

 Upon a successful vote I will upload the archives to dist/, publish them
 to NPM, and post the corresponding blog post.

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 72 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and subdependencies
 have Apache-compatible licenses
 * Ran hello world

 Note: This is the first time we've done an independent platform release,
 and as much as I'd like this thing to go out, it'd be good to smooth-out
 this release process while we're here.  I've added my signing key to
 cordova-dist for verification.  Please keep adding feedback on this in the
 discuss thread.

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Deprecation Wars: ICS vs Gingerbread

[Brian LeRoux]

I agree, we're not really supporting these devices, and it is disingenuous
of the project to advertise that we do. Any apps concerning themselves with
privacy/security won't be targeting or testing on those devices either.

I think a clean break w/ the message 4.x === 4.x, coupled with many
webviews and we have a very solid forward looking release.

On Tue, Jan 13, 2015 at 10:10 AM, Michal Mocny mmo...@chromium.org wrote:

 Does it really matter?  I think Joe summarized it best, we can only claim
 to support what is actually being supported (aka actively tested, actively
 maintained).  Market share doesn't impact that.

 Not that we should not actively break 2.3 support, but with 3.7 on the
 horizon, and big changes coming in 4.0, it would be nice to signal that as
 the last version supporting 2.3 and have us be free to make changes that
 cannot be compatible with the older version.

 -Michal

 On Tue, Jan 13, 2015 at 12:22 PM, Joe Bowser bows...@gmail.com wrote:

  So, where are these numbers coming from?  Can we get a breakdown by
 region?
 
  On Tue Jan 13 2015 at 3:30:23 AM Marcel Kinard cmarc...@gmail.com
 wrote:
 
   Another stat: Forbes estimates that the existing number of Android
 phones
   is 1.56 billion. Five percent of that is 78 million.
  
On Jan 13, 2015, at 1:14 AM, Ally Ogilvie aogil...@wizcorp.jp
 wrote:
   
moar stats:
https://mixpanel.com/trends/#report/android_os_adoption/
   from_date:-365,to_date:0
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 

Re: platforms/plugins save and restore from config.xml

[Brian LeRoux]

Yes! Also quick q, are all experimental flags documented somewhere? (Other
than code)

On Thu, Jan 8, 2015, 6:29 PM Parashuram N (MS OPEN TECH) 
panar...@microsoft.com wrote:

 +1 to graduating this out of experimental :)

 On 1/8/15, 4:25 PM, Steven Gill stevengil...@gmail.com wrote:

 +1 to remove --experimental
 
 On Thu, Jan 8, 2015 at 4:13 PM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:
 
 
 
  On 8 Jan 2015, at 17:29, Mefire O. wrote:
 
   Hi all,
 
  I am a big fan of the experimental save and restore features that
 are
  in the CLI and saw that Gorkem has also created another PR (
  https://github.com/apache/cordova-lib/pull/143 ) to have a setting to
  auto persist/restore plugin versions which is a really interesting
 idea.
 
 
  Glad it helps someone. The current PR is for plugins and I will send a
 PR
  for platforms too. The ultimate goal is to be able to remove platforms
 and
  plugins folder completely.
 
   On a related note, one issue I ran into with platform save/restore is
  when you need to involve multiple operating systems for a given
 project.
  Ex: Targeting say iOS, Windows, and Ubuntu from the same project or
 simply
  have some team members on OSX or Linux while others are on Windows -
 you
  need to be able to save or restore only platforms that run on the
 OS
  you are currently using.
 
  For the restore situation, it seems to make quite a bit of sense to use
  any version information in config.xml when you add a platform by
 default.
  The fact the information in is in config.xml indicates the goal is
  consistency.
 
  Here is a PR that adds this functionality for platforms:
  https://github.com/apache/cordova-lib/pull/140#issuecomment-68942932
 
   This functionality makes a lot of sense especially if/when it supports
  git urls?
 
   With that in mind, we could also follow that familiar pattern that
 exists
  with npm and package.json to help out when you want to quickly save the
  platform you added to config.xml.
 
  Ex:
 
  cordova platform add android --save
 
 
  I think we should have support for --save on plugins add/remove as well.
  Ultimately, I think users of this functionality configure their
 projects to
  be auto restore and use this or the save/restore commands to specify
 what
  needs to be restored.
 
  There is one catch with the implementation though. Save and restore are
  still called with --experimental, perhaps we need to remove
 --experimental
  before this can proceed.
 
   ...adds the latest android platform and updates config.xml with the
  version that was added. As always, you can always use the existing
 syntax
  to add a different version (cordova platform add android@4.0.0mailto:
  android@4.0.0). I'm planning on putting together a PR on that idea as
  well.  We could actually follow a similar model for plugins as well.
 
  Thanks,
  Mefire
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Deprecation Wars: ICS vs Gingerbread

[Brian LeRoux]

I say we go 4.x all in and drop everything below. Time to draw a line.

On Wed, Jan 7, 2015, 6:24 PM Joe Bowser bows...@gmail.com wrote:

 Also, who actually tests on Gingerbread?  Please comment on this thread.

 On Wed Jan 07 2015 at 5:09:49 PM Joe Bowser bows...@gmail.com wrote:

  I'm just mentioning it because my only Android 4.0.3 devices are an ASUS
  Transformer 2 tablet and a Motorola RAZR phone that did weird things to
 my
  computer when I tried installing the extra software to upgrade it.
 
  However, if we did deprecate 2.3, I can just flash 4.0.3 on the Nexus S
  and use that.
 
 
  On Wed Jan 07 2015 at 5:07:27 PM tommy-carlos williams 
 to...@devgeeks.org
  wrote:
 
  It seems to me that if we are only going to drop *one*, that it should
 be
  Gingerbread first, since it is a lower SDK version.
 
  How can an app support GB and *not* ICS?
 
  Having said that, I am also interested in the discussion of better
  numbers on usage than just the Play Store (even if my gut reaction is
  always “BURN 2.3 WITH FIRE”).
 
  --
  tommy-carlos williams
 
  On 8 January 2015 at 10:39:33, Joe Bowser (bows...@gmail.com) wrote:
 
  Hey
 
  So, 2015 is here, and we have the new Android Pie Chart:
 
  http://developer.android.com/about/dashboards/index.html#2015
 
  Due to two percentage points on ICS and three on Gingerbread, we're
 stuck
  supporting these platforms for the near future, but it looks like we're
 in
  the bad spot of them reaching the magic 5% at the same time. Since I
 don't
  like the idea of automatically dropping 10% of devices, I'm wondering
 what
  we should deprecate first.
 
  Also, can we get better numbers for what's out there? Right now we still
  have the only single point of reference, which is the Google Play store.
  This doesn't cover China, or any other emerging markets. That said,
 things
  like Android One, and vendors like Xiaomi are making KitKat and Lolipop
  the
  standard. I know that I'm once again touching off a flame war between
  developers who know that these platforms don't get the tests they need
 to
  be actually considered supported, and various business interests who for
  some unknown reason need this support, but we should have this
 discussion
  again.
 
  Thoughts?
 
  Joe
 
 

Re: Deprecation Wars: ICS vs Gingerbread

[Brian LeRoux]

!

On Wed, Jan 7, 2015, 6:49 PM tommy-carlos williams to...@devgeeks.org
wrote:


 --
 tommy-carlos williams

 On 8 January 2015 at 12:37:59, Brian LeRoux (b...@brian.io) wrote:

 I say we go 4.x all in and drop everything below. Time to draw a line.

 On Wed, Jan 7, 2015, 6:24 PM Joe Bowser bows...@gmail.com wrote:

  Also, who actually tests on Gingerbread? Please comment on this thread.
 
  On Wed Jan 07 2015 at 5:09:49 PM Joe Bowser bows...@gmail.com wrote:
 
   I'm just mentioning it because my only Android 4.0.3 devices are an
 ASUS
   Transformer 2 tablet and a Motorola RAZR phone that did weird things
 to
  my
   computer when I tried installing the extra software to upgrade it.
  
   However, if we did deprecate 2.3, I can just flash 4.0.3 on the Nexus
 S
   and use that.
  
  
   On Wed Jan 07 2015 at 5:07:27 PM tommy-carlos williams 
  to...@devgeeks.org
   wrote:
  
   It seems to me that if we are only going to drop *one*, that it
 should
  be
   Gingerbread first, since it is a lower SDK version.
  
   How can an app support GB and *not* ICS?
  
   Having said that, I am also interested in the discussion of better
   numbers on usage than just the Play Store (even if my gut reaction is
   always “BURN 2.3 WITH FIRE”).
  
   --
   tommy-carlos williams
  
   On 8 January 2015 at 10:39:33, Joe Bowser (bows...@gmail.com) wrote:
  
   Hey
  
   So, 2015 is here, and we have the new Android Pie Chart:
  
   http://developer.android.com/about/dashboards/index.html#2015
  
   Due to two percentage points on ICS and three on Gingerbread, we're
  stuck
   supporting these platforms for the near future, but it looks like
 we're
  in
   the bad spot of them reaching the magic 5% at the same time. Since I
  don't
   like the idea of automatically dropping 10% of devices, I'm wondering
  what
   we should deprecate first.
  
   Also, can we get better numbers for what's out there? Right now we
 still
   have the only single point of reference, which is the Google Play
 store.
   This doesn't cover China, or any other emerging markets. That said,
  things
   like Android One, and vendors like Xiaomi are making KitKat and
 Lolipop
   the
   standard. I know that I'm once again touching off a flame war between
   developers who know that these platforms don't get the tests they
 need
  to
   be actually considered supported, and various business interests who
 for
   some unknown reason need this support, but we should have this
  discussion
   again.
  
   Thoughts?
  
   Joe
  
  
 

Re: Auto-suffixing debug app id on Android

[Brian LeRoux]

So two apps, same name on the springboard/deck, but diff id?

On Tue, Jan 6, 2015, 7:46 PM Tommy Williams to...@devgeeks.org wrote:

 As handy as having release and debug on the same device might be, this
 might be a job for a hook and a blog post about it, instead of a built in
 feature.
 On 07/01/2015 1:29 pm, Andrew Grieve agri...@chromium.org wrote:

  Nope no JIRA, just something I stumbled across when I was reading gradle
  docs and thought I'd bring up. One other thing it avoids is getting the
  certificate mismatch failure when you switch between release and debug.
  Good point about being confused as to which icon is which though.
 
  On Tue, Jan 6, 2015 at 7:55 PM, Joe Bowser bows...@gmail.com wrote:
 
   I don't think this idea is entirely thought out.  I've had debug and
   release code on devices, and all it does is confuse me when I need to
 do
  a
   demo of something.  Is there a JIRA issue regarding this new feature,
  since
   I think this needs to be fleshed out more.
  
   On Tue Jan 06 2015 at 10:42:51 AM Andrew Grieve agri...@chromium.org
   wrote:
  
Mainly - it allows it to be installed alongside the release version
 of
   the
app.
   
On Tue, Jan 6, 2015 at 11:01 AM, Brian LeRoux b...@brian.io wrote:
   
 Why is it a good idea?

 On Tue, Jan 6, 2015, 7:40 AM Andrew Grieve agri...@google.com
  wrote:

  With gradle, this is easy to do:
 
  android {
  buildTypes {
  debug {
  applicationIdSuffix .debug
  }
 
  Seems like a good idea to me, but I'm wondering if there may be
   reason
 not
  to?
 

   
  
 

Re: Auto-suffixing debug app id on Android

[Brian LeRoux]

Why is it a good idea?

On Tue, Jan 6, 2015, 7:40 AM Andrew Grieve agri...@google.com wrote:

 With gradle, this is easy to do:

 android {
 buildTypes {
 debug {
 applicationIdSuffix .debug
 }

 Seems like a good idea to me, but I'm wondering if there may be reason not
 to?

Re: Steroids Tooling now supports Cordova projects out of the box

[Brian LeRoux]

Hi Harri, we are thrilled to see downstream distributions of Cordova. That
is the design! However, marketing related messaging and feedback requests
are not appropriate for this list unless you are looking for our help
contributing your code into Cordova directly.

Thx!

On Fri, Dec 26, 2014 at 2:41 AM, Harri Sarsa harri.sa...@appgyver.com
wrote:

 Hey,

 don't know how familiar y'all are with the latest at AppGyver, but we just
 published a version of our [Steroids Tooling](
 http://www.appgyver.com/steroids/) that allows you to to use our tooling
 with Cordova projects without making changes to the project folder. Check
 out the guide at http://docs.appgyver.com/tooling/cli/usage-with-cordova/
 for more!

 That means you can develop locally without Xcode/Android Studio with our
 Scanner companion app, use the QR code sharing, utilize our build service
 etc.

 It's still an experimental feature, and our wrapper runs our own fork of
 Cordova (backwards-compatible though), but it'd be great to hear some
 feedback from you guys!

 Best,
 Harri Sarsa
 AppGyver, Inc.

Re: Reason for node_modules in Platform Repos

[Brian LeRoux]

First link from a Google search about checking in node modules.

http://stackoverflow.com/questions/11459475/should-i-check-in-node-modules-to-git-when-creating-a-node-js-app-on-heroku

While useful to question assumptions (always) we should also strive to
respect the best practices and standards for the platforms we target. Maybe
that's obvious but bears repeating.

On Friday, December 19, 2014, Dmitry Blotsky dblot...@microsoft.com wrote:

 Hey folks,

 Thanks for the feedback! I agree with Josh, that requiring active
 dependency resolution introduces an extra point of failure. Even if a
 corporate network is fast and reliable, it has been explained to me that it
 is possible for a third-party dependency provider to pull their package
 from NPM, thus breaking a platform install. Keeping the dependency code
 inside the platform repo makes the code more robust. That does seem like a
 valid reason to do things the way we are doing them. Perhaps though, it
 should be mentioned in the documentation that that is how package
 repositories handle dependencies. I created a JIRA issue for this:
 https://issues.apache.org/jira/browse/CB-8195.

 As for getting feet wet, I am currently getting up to speed with the
 effort to get Cordova Medic on Apache Infrastructure, as per this JIRA
 ticket: https://issues.apache.org/jira/browse/INFRA-8588.

 Kindly,

 Dmitry

 -Original Message-
 From: brian.ler...@gmail.com javascript:; [mailto:brian.ler...@gmail.com
 javascript:;] On Behalf Of Brian LeRoux
 Sent: Friday, December 19, 2014 1:04 PM
 To: dev@cordova.apache.org javascript:;
 Subject: Re: Reason for node_modules in Platform Repos

 Josh, you are really abrasive and need to work on that.

 The corp network thing isn't a reason for anyone except RIM and Adobe IT
 departments and even then its not a real reason. If we architect for bad IT
 departments we may as well go full Apache Way and have singular SVN repo
 with 50% uptime and a 10 year release cycle.

 These are not hand waving statements. Using a package.json for deps is a
 well documented and understood practice. Someone *should* write some code
 and this would be a great first patch for a new developer looking to get
 their feet wet with the project.





 On Fri, Dec 19, 2014 at 12:48 PM, Josh Soref jso...@blackberry.com
 javascript:; wrote:

  Brian LeRoux wrote:
  yeh, we've been through this in other threads. pin the dep in
  package.json to a version or sha and your problem is solved. the only
  time a node_modules should be checked in, maybe, is in a deployment
  scenario for hosted service type things.
  
  (bad corp networks aside!)
 
  Bad corporate networks exist. And they block ssh: (I.e. git:).
 
  It's really painful to have things fail just because someone decided
  to use git://github.com instead of https://github.com …
 
 
 
  I'm also pretty sure that we don't currently have the right code to
  actually get dependencies and install them when we do a platform add.
  So while you may want to make a hand waving statement about we should
  stop doing this, someone would almost certainly have to write code to
  make it do the right thing.
 
  Further, that doesn't fix the case I've described above.
 
  I don't see a reason to change the status quo, and I have identified a
  reason not to change it.
 

Re: Reason for node_modules in Platform Repos

[Brian LeRoux]

none. go fix it!

On Fri, Dec 19, 2014 at 12:07 PM, Dmitry Blotsky dblot...@microsoft.com
wrote:

 Hi all,

 What was the design decision and reasoning behind full node_module
 directories being committed to platform repositories along with the source,
 instead of being installed from the respective package.json at the time
 that the platform is obtained?

 Kindly,

 Dmitry Blotsky

Re: Reason for node_modules in Platform Repos

[Brian LeRoux]

yeh, we've been through this in other threads. pin the dep in
package.json to a version or sha and your problem is solved. the only time
a node_modules should be checked in, maybe, is in a deployment scenario for
hosted service type things.

(bad corp networks aside!)

On Fri, Dec 19, 2014 at 12:18 PM, Josh Soref jso...@blackberry.com wrote:

 Not true!

 It was for stability so that we wouldn't be reliant on various things that
 could fail/change/flake.

 Personally, in our network environment, any project which decides to
 reference a git: url becomes unimportable.

 If they happen to be transcluded via packaged node_modules, then this is a
 non-issue.

 On 12/19/14, 3:16 PM, Brian LeRoux b...@brian.io wrote:

 none. go fix it!
 
 On Fri, Dec 19, 2014 at 12:07 PM, Dmitry Blotsky dblot...@microsoft.com
 wrote:
 
  Hi all,
 
  What was the design decision and reasoning behind full node_module
  directories being committed to platform repositories along with the
 source,
  instead of being installed from the respective package.json at the time
  that the platform is obtained?

Re: Reason for node_modules in Platform Repos

[Brian LeRoux]

Josh, you are really abrasive and need to work on that.

The corp network thing isn't a reason for anyone except RIM and Adobe IT
departments and even then its not a real reason. If we architect for bad IT
departments we may as well go full Apache Way and have singular SVN repo
with 50% uptime and a 10 year release cycle.

These are not hand waving statements. Using a package.json for deps is a
well documented and understood practice. Someone *should* write some code
and this would be a great first patch for a new developer looking to get
their feet wet with the project.





On Fri, Dec 19, 2014 at 12:48 PM, Josh Soref jso...@blackberry.com wrote:

 Brian LeRoux wrote:
 yeh, we've been through this in other threads. pin the dep in
 package.json to a version or sha and your problem is solved. the only time
 a node_modules should be checked in, maybe, is in a deployment scenario
 for
 hosted service type things.
 
 (bad corp networks aside!)

 Bad corporate networks exist. And they block ssh: (I.e. git:).

 It's really painful to have things fail just because someone decided to
 use git://github.com instead of https://github.com …



 I'm also pretty sure that we don't currently have the right code to
 actually get dependencies and install them when we do a platform add. So
 while you may want to make a hand waving statement about we should stop
 doing this, someone would almost certainly have to write code to make it
 do the right thing.

 Further, that doesn't fix the case I've described above.

 I don't see a reason to change the status quo, and I have identified a
 reason not to change it.

Re: Apache license in cordova create

[Brian LeRoux]

go for it; pretty sure you'll get the same answer tho

(we have to license stuff we distribute but we could strip on create)


On Sun, Dec 14, 2014 at 3:40 PM, Parashuram Narasimhan (MS OPEN TECH) 
panar...@microsoft.com wrote:

 Maybe we could ask legal-disc...@apache.org about this issue? They should
 be able to give us a definitive answer about the alternatives.

 From: Brian LeRoux
 Sent: ‎Wednesday‎, ‎December‎ ‎10‎, ‎2014 ‎12‎:‎46‎ ‎PM
 To: dev@cordova.apache.org

 guess so yea, great first patch Martin ;)

 On Wed, Dec 10, 2014 at 12:32 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Could we just strip the license as a part of the create script?
 
  On Wed, Dec 10, 2014 at 2:30 PM, Brian LeRoux b...@brian.io wrote:
 
   recent discussions elsewhere indicate (to me) that while the ASL
 (apache
   software license) is compatible with other licenses but the ASF (apache
   software foundation) doesn't want to conflate our source with other
 ones
   (reasonable imo)
  
  
   On Wed, Dec 10, 2014 at 11:21 AM, Josh Soref jso...@blackberry.com
   wrote:
  
In theory, shouldn't we be able to put that file under an MIT/BSD
  license
to make people happier?
   
Getting sample content to be usable by others is a pain, and
 something
that is one of the last steps people work on.
   
I think Mozilla moved its tests to MIT to address this.
   
I have no idea what Apache's policy is.
   
Unfortunately, I can't find any good examples of this…
   
   
  
 
 https://github.com/eclipsesource/raspberry-pi-examples/blob/master/com.ecli
   
  
 
 psesource.iot.photosensor-example/src/com/eclipsesource/iot/photosensor/exa
mple/Main.java
   
Has an Eclipse license on a sample, which is probably just as bad.
   
   
  
 
 http://hg.netbeans.org/main/file/23e994b27837/apisupport.crudsample/crud-sa
mple-application/CustomerDBAccess/src/demo/Customer.java
   
Has GPL/CDDL. GPL is clearly useless. I'm not sure CDDL is more
 helpful
than Apache.
   
   
   
  
 
 http://www.contactandcoil.com/software/a-very-fast-tutorial-on-open-source-
licenses/
   
   
  
 
 http://mail-archives.apache.org/mod_mbox/cayenne-dev/200710.mbox/%3C62FEC22
5-fe92-476b-84c1-69869b179...@objectstyle.org%3E
   
http://apache.org/legal/3party.html#category-a
   
   
  
 
 http://opendata.stackexchange.com/questions/245/cc-by-vs-mit-or-bsd-license
s-regarding-re-use
   
   
https://wiki.creativecommons.org/CC0_FAQ
   
   
I think we should probably get permission and relicense those files
 as
CC-0.
   
CC-0 isn't in the list that Apache has whitelisted, but I think we
  should
be able to convince apache that this is the right license for these
  files
(and similar template files to be used to generate content that a
   consumer
is supposed to be able to do w/ however they please).
   
On 12/10/14, 2:02 PM, Brian LeRoux b...@brian.io wrote:
   
no mistake, but it is a requirement for us to distribute code at
  apache.
you are free to remove and relicense as you wish.

On Wed, Dec 10, 2014 at 9:49 AM, Martin Sidaway msida...@gmail.com
 
wrote:

 I'm a bit puzzled by the Apache license notice present in the
   following
 files after doing cordova create:

 www/index.html
 www/js/index.js
 www/css/index.css

 The trouble is that if I begin my project by extending those
 files,
  it
 seems like the Apache license covers my changes as well as the
   original
 template. It also seems like I am saying that my changes are
  licensed
to
 the Apache Software Foundation under one or more contributor
 license
 agreements. And it doesn't seem like the Apache license would
 allow
   me
to
 remove those notices.

 So am I right in thinking that if I want to develop software that
 I
might
 not intend to be Apache-licensed and/or licensed to ASF, I have to
delete
 these 3 files and start from scratch?

 This sort of thing seems a little inappropriate in a template.
   Basically
 what it means is that I have to (1) work out what the template
 does
   and
 which parts I actually need to begin a project, (2) rewrite those
   parts
by
 hand (basic html document structure, meta/viewport tag, etc.)
 taking
care
 not to resort to copy/paste, (3) gradually realise that the
 aspects
  of
my
 app that behave inconveniently on certain platforms correspond to
things I
 chose not to copy over from the template.

 Is there any other way to approach this? Is it a mistake?

 Thanks.

   
   
  
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Browserify JS is in

[Brian LeRoux]

yeah we are *not* proposing to distribute browserify or its deps

On Fri, Dec 12, 2014 at 1:38 PM, Joe Bowser bows...@gmail.com wrote:

 What are we actually distributing?

 On Fri Dec 12 2014 at 12:36:03 PM Andrew Grieve agri...@chromium.org
 wrote:

  On Fri, Dec 12, 2014 at 1:51 PM, Joe Bowser bows...@gmail.com wrote:
 
   On Fri Dec 12 2014 at 10:25:51 AM Andrew Grieve agri...@chromium.org
   wrote:
  
   
I'm not actually worried about my disk filling up. Dependencies must
 be
vetted for appropriate licenses, so now there's more overhead here.
 If
  we
need to make a change to the module system now we need to poor
 through
   docs
and make PRs instead of just editing our very small code-base.
   
   
   This mix of MIT and 3-Clause BSD looks compatible to me.  It's weaker
  than
   Apache, but not incompatible.  Do we really need to send this to legal?
   https://github.com/substack/node-browserify/blob/master/LICENSE
  
   There are people who can argue your other points better, but saying
 that
   the license is the overhead when you can find it in the repo?  I'm not
  sure
   how we would have gotten this far if we had to check with legal for
 every
   single dependency.
  
 
  I meant that it depends on a bunch of other modules. Run license-checker
 on
  browserify and you get: http://pastebin.com/XDMCTRRb
 

Re: WebView Promise and W3C standards

[Brian LeRoux]

you could do sneakier haicker things …at any rate -1 on promises remains
the case

On Fri, Dec 12, 2014 at 12:25 PM, Jesse purplecabb...@gmail.com wrote:

 Oops, I was wrong.  My test works on the first page loaded, but any page
 after that it does not. Your faith was well placed. I won't bother trying
 Android, as no-iOS is a blocker.



  On Dec 12, 2014, at 11:55 AM, Andrew Grieve agri...@chromium.org
 wrote:
 
  On Fri, Dec 12, 2014 at 2:28 PM, Jesse purplecabb...@gmail.com wrote:
 
  On Fri, Dec 12, 2014 at 11:10 AM, Shazron shaz...@gmail.com wrote:
 
  Yup, WKWebView has an option to add a script at
  WKUserScriptInjectionTimeAtDocumentStart.
 
  On Fri, Dec 12, 2014 at 7:21 AM, Andrew Grieve agri...@chromium.org
  wrote:
  I believe there's not API to insert this early for Android / iOS other
  than
  in the new WKWebView.
 
  On iOS you can inject js code in webViewDidStartLoad, which is evaluated
  and available before any other js loads/runs. Science before belief.
  I will run a similar test on Android.
  This is sadly not the case. You're still in the context of the previous
  page when this is fired.
 
 
 
 
 
 
 
  On Thu, Dec 11, 2014 at 3:23 PM, Jesse purplecabb...@gmail.com
  wrote:
 
  The native side knows the browser capabilities long before it's
  loaded, or even created, compile time even. They will never change
  after the app is built.
  On WP8 the scripts are injected right before DOMContentLoaded fires,
  and before any js code in the page is run.  I realize other platforms
  may not be able to catch the browser load events early enough to be
  effective though. Anyone know the native side event flow for
  iOS+Android?
 
  On Dec 11, 2014, at 10:54 AM, Andrew Grieve agri...@chromium.org
  wrote:
 
  Let's start a new thread for browserify.
 
  Jesse - def. like the idea of injecting polyfills when they are not
  there
  but are required. In practice though, I think it ends up pretty much
  the
  same anyways:
  - On start-up you need to feature-detect Promise via JS
  - If it's not there, you need to inject it.
 
  Whether the injection occurs via the native side shoving it in, or
  by
  cordova.js require()'ing a module is a matter of whether we check in
  es6-promise.js into each platform separately, or into cordova-js.
 
 
  On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:
 
  we should move browserify to main and drop that insane concat code
 
  its not heavyweight at all. it creates a hash in iife with deps
  mapped
  in…as to why dep mgmt is better than concatenating…I don't think we
  need to
  waste our time talking about that!
 
  On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve 
  agri...@chromium.org
 
  wrote:
 
  There's something implemented behind a --browserify flag, but not
  sure
  what
  it does.
 
  Totally in favour of having CLI / plugman concatenate plugin JS
  with
  cordova.js, but not convinced that browserify is the right tool
  for
  this,
  as it seems quite heavy-weight for just concatenating things. If
  someone
  is
  going to resume work on it, would love to hear a summary of what
  problems
  it's solving (if more than concatenation), and why something more
  light-weight wouldn't be better.
 
  On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny 
  mmo...@chromium.org
 
  wrote:
 
  We haven't worked on it, also curious.  Anis, perhaps?
 
  On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io
  wrote:
 
  def think we should support those specs in our great and fabled
  api
  audit…had not considered the load order issue
 
  not insurmountable and probably should be a feature/fix for the
  plugin
  loader load order …but also sort of scary… reminds me of script
  tags
  hell
 
  on that note: we need to make browserify thing first class.
  whats
  the
  hold
  up on that front?
 
  On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny 
  mmo...@chromium.org
  wrote:
 
  Do we prefer to invent new cordova-specific apis, or prefer to
  match
  standard browser apis?  When there is no browser spec to match
  then
  design
  comes down to aesthetics and personal preference (as you say).
  But
  often
  there is an existing browser spec, and then it comes down to
  match
  or
  fork.  I'm in the camp of preferring to match, and was under
  the
  assumption
  others here were too.
 
  Given the upcoming specs mentioned earlier (sockets, file,
  filesystem,
  permissions, service worker, fetch), seems that fighting the
  adoption
  of
  promises in core apis implies opposing the adoption of modern
  web
  specs.
  e.g. I'm assuming Andrew was referring to
  http://www.w3.org/TR/battery-status/, since matching that spec
  *would*
  require promises.
 
 
  Now, as I understand, you are not saying you are opposed to
  adoption
  of
  promises in Cordova, but that you are simply against the
  inclusion
  of a
  polyfill directly inside cordova-js.  I think that a
  promises-polyfill
  plugin alternative has some technical downsides [1

Re: Browserify JS is in

[Brian LeRoux]

so I think this has baked long enough! lets make it the default and suss
the bugs.

On Thu, Jul 10, 2014 at 3:36 AM, Ally Ogilvie aogil...@wizcorp.jp wrote:

 Ace, look forward to browser/web as platform. Combined Web and Native API
 plugin for Cordova! Yay!
 Thanks for the clarification Michal.



 On Tue, Jul 8, 2014 at 6:07 AM, Anis KADRI anis.ka...@gmail.com wrote:

  Right, browserify is just a way to package cordova.js that should make it
  easier to add the browser as a platform so might not be directly related
  but is somewhat related :-}
 
 
  On Mon, Jul 7, 2014 at 4:45 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
   I think Ally may be confusing what this does?: This browserify work is
  not
   a way to get cordova to run in a desktop browser, its just a means for
   packaging cordova.js.  I think there should be no visible change to end
   users.
  
   There is a separate effort to target the browser as a platform, and it
  may
   be true that the browserify work helps with that, but its not directly
   related.
  
  
   On Mon, Jul 7, 2014 at 3:58 PM, Anis KADRI anis.ka...@gmail.com
 wrote:
  
On Sun, Jun 29, 2014 at 9:54 PM, Ally Ogilvie aogil...@wizcorp.jp
   wrote:
   
 Anis that is really sweet.
 If this hits CLI, plugin.xml will have sections for plugins to do
 web
 actions?

   
Not sure I understand what you mean by web actions.
   
   
 TBH.. i've always wanted a cordova platform add web... but i'd be
  happy
 enough with a prepare for browser only mode.

   
`cordova platform add web` is part of the plan.
   
   

 Seeing a lot of use cases (e.g. Facebook plugin etc.) where there
 are
   JS,
 iOS  Android SDKs and a Cordova Plugin wants to support the same
 API
   on
 all platforms.

   
Didn't think of that but it is applicable indeed.
   
   



 On Sat, Jun 21, 2014 at 9:26 AM, Anis KADRI anis.ka...@gmail.com
wrote:

  Ok cool. I can look at adding a --browserify option for run and
prepare.
 I
  logged an issue for it [1]
 
  [1] https://issues.apache.org/jira/browse/CB-7001
 
 
  On Thu, Jun 19, 2014 at 5:57 PM, Andrew Grieve 
  agri...@chromium.org
   
  wrote:
 
   Thanks Anis!
  
   Tougher for CLI since it's actually the prepare step that
 creates
   cordova_plugins.js, but longer term (medium term?) I don't see
  why
   we
   shouldn't just turn it on always anyways.
  
   So... Maybe cordova prepare --browserify?
   Build prepares first, so will also need: cordova run android
 --browserify
  
   I haven't looked at it yet. Google IO is next week and it's
 been
  consuming
   most of our time the last few weeks. Will definitely play with
 it
next
  next
   week though!
  
  
  
   On Thu, Jun 19, 2014 at 6:28 PM, Anis KADRI 
  anis.ka...@gmail.com
  wrote:
  
   Sorry. I forgot you asked the question. There was no issue but
   there
 is
   one now.
   https://issues.apache.org/jira/browse/CB-6990
  
   This feature is plugman only for now. How important is it to
   wire
it
   to CLI ? Have  you guys had time to test it out yet ? How
 would
  it
   work with CLI ? Add another flag such as cordova plugin add
   --browserify ?
  
   On Thu, Jun 19, 2014 at 9:28 AM, Andrew Grieve 
agri...@chromium.org
   wrote:
bump
   
   
On Mon, Jun 16, 2014 at 12:51 PM, Andrew Grieve 
 agri...@chromium.org
  
wrote:
   
Cool, yes! Thanks for the update!
   
Is there a JIRA for this? Was asked in
https://issues.apache.org/jira/browse/CB-5671.
   
   
   
   
On Mon, Jun 16, 2014 at 10:21 AM, Michal Mocny 
 mmo...@chromium.org
wrote:
   
Awesome Anis.
   
Will gladly take a look at this later today.  Just wanted
 to
send
 a
   quick
thanks for landing this this way, and for the useful
 report.
   
-Michal
   
   
On Fri, Jun 13, 2014 at 7:55 PM, Anis KADRI 
anis.ka...@gmail.com
 
   wrote:
   
 Yo,

 Just wanted to let everyone know that I added browserify
support
  to
 plugman (behind a flag for now). CLI is not hooked to
 this
yet.
  Here
 is how it works:

 plugman install --browserify --plugin [PLUGIN]
 --platform
  [PLATFORM]
 --project [PROJECT_PATH]

 will generate a browserify version of cordova.js.
 Plugins
   and
 everything is bundled in. This version passes
 mobile-spec
  on
iOS
  and
 Android. I am not yet setup to test other platforms.

 plugman install --plugin [PLUGIN] --platform [PLATFORM]
 --project
 [PROJECT_PATH]

 Will continue to generate 

Re: Browserify JS is in

[Brian LeRoux]

I've vetted webpack (and the rest) extensively. Less ecosystem. More
complex config. No transforms.

Here's a thing I wrote on the modules front. Not directly applicable but
possibly relevant and at worst geek entertaining. ;)

https://medium.com/@brianleroux/es6-modules-amd-and-commonjs-c1acefbe6fc0


On Thu, Dec 11, 2014 at 2:11 PM, Steven Gill stevengil...@gmail.com wrote:

 Realized I wasn't clear, but startup/run time is definitely faster. One of
 the benefits of switching to a system like this.

 Build time is a few ms slower.

 On Thu, Dec 11, 2014 at 2:06 PM, Steven Gill stevengil...@gmail.com
 wrote:

 
 
  On Thu, Dec 11, 2014 at 1:45 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
  25MB is for the one-time cordova-cli install, and not overhead for the
  app.  Its not perfect but not a blocker imho.
 
 
  Agreed
 
 
  There are more troubling things about the change than the size overhead:
  - I don't think browserify has baked at all.  It was landed behind a
  flag, but is it actually used anywhere?
 
  - Why browserify and not webpack (aside: its 13Mb..)?  Was it compared at
  all..
 
 
  Not sure. I am unfamiliar with webpack.
 
  But one is integrated into our system...
 
  The node community are big backers of browserify. It had a dedicated
 track
  at JSFEST this week. Not suggesting popularity be the deciding factor
  though :P
 
 
 
  - Last time it was discussed, there were still several breaking changes
  for
  plugins.  Were they resolved?
 
  Yes. Transforms were used to deal with the issues.
 
 
  Anyway, how can we get data on the change to see if it is positive?:
  - Existing plugins continue to work (We run mobile spec, and get
  downstream
  distributions run tests on their plugins).
 
 
  Android and IOS had same success rate on mobile spec for browserify
 system
  last time I tested. Need to do more tests with other platforms. Seems one
  way to get platforms to test it is to make default + fix any problems we
  see before releasing
 
  - Startup time is not negatively affected.
 
 
  Current system we have to read cordova_plugins at runtime. Browserify
  handles this at build time so I would imagine it would speed up that
 part.
  Flip side, all the plugins get executed immediately with browserify (has
  benefits too).
 
  - Build/prepare time is not negatively affected.
 
 
  Is that fair?
 
  -Michal
 
  On Thu, Dec 11, 2014 at 2:38 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   I'd really like to get it fully spelled out *why* browserify is the
  right
   tool for this. Some thoughts below:
  
   On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:
  
we should move browserify to main and drop that insane concat code
   
its not heavyweight at all. it creates a hash in iife with deps
 mapped
in...as to why dep mgmt is better than concatenating...I don't
 think we
  need
   to
waste our time talking about that!
  
  
  
   What makes the concat code insane?
- It's easy to understand and make changes to
- It seems to work fine and is quite stable
- It has no dependencies (it's 52kb within cordova-js/tasks/lib)
  
   Browserify seems a bit scary to me:
   - It's 25MB and has a tonne of dependencies
   - Do we really need all of that functionality?
  
   I think it would actually help a lot to talk about dependency
  management.
   - Right now cordova-js creates a module for every file in src/
   - Plugins list each module explicitly in their plugin.xml
   With browserify, are you envisioning that this model change at all?
  
  
   Why change anything?
   - cordova-lib should concat plugin modules with cordova.js on prepare
  (this
   is the motivation stated in the JIRA. totally on board with this!)
   What else would I like to see changed?
   - exec.js (and any other platform-specific modules) should move to
 live
  in
   platform repos
 - This will make code changes that affect both much easier
   - Platforms should depend on cordova-js via package.json and snapshot
   generation should happen in bin/create as well as plugin add/rm
 - This will remove the (somewhat) annoying step of snapshotting
 - This will allow cordova-js to be released as it's own artifact
   - Good because we can do things like add Promise polyfill and not
  need
   to release all platforms to pick it up
   - A bit annoying since it's one more thing to release, but likely
  won't
   get released often.
  
  
   Please don't look at my email as trying to derail the work Anis did. I
   believe most of it is necessary to accomplish these goals whether we
 use
   Browserify, our own, or some other concattenator. I just question
  whether
   25MB is too much complexity for what we need / want.
  
  
  
  
   On Thu, Dec 11, 2014 at 2:10 PM, Joe Bowser bows...@gmail.com
 wrote:
  
This should be a major, but yeah, I'm fine with making this the
  default.
   
On Thu, Dec 11, 2014, 11:08 AM Brian LeRoux b...@brian.io wrote:
   
 so

Re: WebView Promise and W3C standards

[Brian LeRoux]

- no technical benefit (but aesthetics, sure)
- adds weight (payload and runtime)
- might interfere with userland polly

-1

On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve agri...@chromium.org wrote:

 One specific spot in core I'd like to use it is to address this TODO in
 Android's exec bridge:

 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263

 The actual need is for a setImmediate polyfill, but Promise does the same
 thing (with an extra object creation).

 On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland iclell...@chromium.org
 wrote:

  On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve agri...@chromium.org
  wrote:
 
   userland means that plugins won't be able to use them unless every
 plugin
   also includes a copy of the polyfill within it.
  
   Looking at our core APIs, seems maybe it's just battery-status that
 will
   require it. Should we have battery-status include the polyfill within
  it? I
   hope not. I'd hate to get to where several plugins in my app all bundle
  the
   same polyfill.
  
 
  I believe that Mozilla's new File API, which I think we're planning to
  implement, and which should be as core as File is now, is also heavily
  promises-based.
 
 
  
   If we move to having the entire cordova.js built using browserify where
   every plugin gets to contribute to the JS that goes into it - yes I can
  see
   this solving this use-case as well. But that also seems to me like a
 much
   larger and much more controversial change.
  
   Whether you are for or against promises - they are already here. They
   exists natively on most latest mobile webviews, and every vendor has
   committed to adding them. And they are being used in *most* new specs
  that
   I've seen (sockets, filesystem, permissions, service worker, fetch)
  
   Are there any concrete downsides to putting Promises polyfill right in
   cordova-js?
  
 
  As long as the promise doesn't clobber the native implementation, if it
  exists, and we can remove it completely from platforms when they don't
 need
  it anymore, it seems to me like a small price for having this available
 to
  all platforms. (Other opinions vary, I'm sure, though)
 
 
  
  
   On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser bows...@gmail.com wrote:
  
+1 to userland. I see other approaches causing more problems.
   
BTW: The only time I use promises is when the platform explicitly
   requires
it, and right now that's just MozillaView.  While I think it looks
   awesome,
I view Promises as a luxury right now and not a standard feature as
 of
   yet.
   
I also really wish specs wouldn't rely on code that only exists on
 the
   very
latest browsers. It just makes life harder on people who have to
   implement
stuff.
   
  
 

Re: Apache license in cordova create

[Brian LeRoux]

no mistake, but it is a requirement for us to distribute code at apache.
you are free to remove and relicense as you wish.

On Wed, Dec 10, 2014 at 9:49 AM, Martin Sidaway msida...@gmail.com wrote:

 I'm a bit puzzled by the Apache license notice present in the following
 files after doing cordova create:

 www/index.html
 www/js/index.js
 www/css/index.css

 The trouble is that if I begin my project by extending those files, it
 seems like the Apache license covers my changes as well as the original
 template. It also seems like I am saying that my changes are licensed to
 the Apache Software Foundation under one or more contributor license
 agreements. And it doesn't seem like the Apache license would allow me to
 remove those notices.

 So am I right in thinking that if I want to develop software that I might
 not intend to be Apache-licensed and/or licensed to ASF, I have to delete
 these 3 files and start from scratch?

 This sort of thing seems a little inappropriate in a template. Basically
 what it means is that I have to (1) work out what the template does and
 which parts I actually need to begin a project, (2) rewrite those parts by
 hand (basic html document structure, meta/viewport tag, etc.) taking care
 not to resort to copy/paste, (3) gradually realise that the aspects of my
 app that behave inconveniently on certain platforms correspond to things I
 chose not to copy over from the template.

 Is there any other way to approach this? Is it a mistake?

 Thanks.

Re: Apache license in cordova create

[Brian LeRoux]

recent discussions elsewhere indicate (to me) that while the ASL (apache
software license) is compatible with other licenses but the ASF (apache
software foundation) doesn't want to conflate our source with other ones
(reasonable imo)


On Wed, Dec 10, 2014 at 11:21 AM, Josh Soref jso...@blackberry.com wrote:

 In theory, shouldn't we be able to put that file under an MIT/BSD license
 to make people happier?

 Getting sample content to be usable by others is a pain, and something
 that is one of the last steps people work on.

 I think Mozilla moved its tests to MIT to address this.

 I have no idea what Apache's policy is.

 Unfortunately, I can't find any good examples of this…

 https://github.com/eclipsesource/raspberry-pi-examples/blob/master/com.ecli
 psesource.iot.photosensor-example/src/com/eclipsesource/iot/photosensor/exa
 mple/Main.java

 Has an Eclipse license on a sample, which is probably just as bad.

 http://hg.netbeans.org/main/file/23e994b27837/apisupport.crudsample/crud-sa
 mple-application/CustomerDBAccess/src/demo/Customer.java

 Has GPL/CDDL. GPL is clearly useless. I'm not sure CDDL is more helpful
 than Apache.


 http://www.contactandcoil.com/software/a-very-fast-tutorial-on-open-source-
 licenses/

 http://mail-archives.apache.org/mod_mbox/cayenne-dev/200710.mbox/%3C62FEC22
 5-fe92-476b-84c1-69869b179...@objectstyle.org%3E

 http://apache.org/legal/3party.html#category-a

 http://opendata.stackexchange.com/questions/245/cc-by-vs-mit-or-bsd-license
 s-regarding-re-use


 https://wiki.creativecommons.org/CC0_FAQ


 I think we should probably get permission and relicense those files as
 CC-0.

 CC-0 isn't in the list that Apache has whitelisted, but I think we should
 be able to convince apache that this is the right license for these files
 (and similar template files to be used to generate content that a consumer
 is supposed to be able to do w/ however they please).

 On 12/10/14, 2:02 PM, Brian LeRoux b...@brian.io wrote:

 no mistake, but it is a requirement for us to distribute code at apache.
 you are free to remove and relicense as you wish.
 
 On Wed, Dec 10, 2014 at 9:49 AM, Martin Sidaway msida...@gmail.com
 wrote:
 
  I'm a bit puzzled by the Apache license notice present in the following
  files after doing cordova create:
 
  www/index.html
  www/js/index.js
  www/css/index.css
 
  The trouble is that if I begin my project by extending those files, it
  seems like the Apache license covers my changes as well as the original
  template. It also seems like I am saying that my changes are licensed
 to
  the Apache Software Foundation under one or more contributor license
  agreements. And it doesn't seem like the Apache license would allow me
 to
  remove those notices.
 
  So am I right in thinking that if I want to develop software that I
 might
  not intend to be Apache-licensed and/or licensed to ASF, I have to
 delete
  these 3 files and start from scratch?
 
  This sort of thing seems a little inappropriate in a template. Basically
  what it means is that I have to (1) work out what the template does and
  which parts I actually need to begin a project, (2) rewrite those parts
 by
  hand (basic html document structure, meta/viewport tag, etc.) taking
 care
  not to resort to copy/paste, (3) gradually realise that the aspects of
 my
  app that behave inconveniently on certain platforms correspond to
 things I
  chose not to copy over from the template.
 
  Is there any other way to approach this? Is it a mistake?
 
  Thanks.
 

Re: Apache license in cordova create

[Brian LeRoux]

guess so yea, great first patch Martin ;)

On Wed, Dec 10, 2014 at 12:32 PM, Andrew Grieve agri...@chromium.org
wrote:

 Could we just strip the license as a part of the create script?

 On Wed, Dec 10, 2014 at 2:30 PM, Brian LeRoux b...@brian.io wrote:

  recent discussions elsewhere indicate (to me) that while the ASL (apache
  software license) is compatible with other licenses but the ASF (apache
  software foundation) doesn't want to conflate our source with other ones
  (reasonable imo)
 
 
  On Wed, Dec 10, 2014 at 11:21 AM, Josh Soref jso...@blackberry.com
  wrote:
 
   In theory, shouldn't we be able to put that file under an MIT/BSD
 license
   to make people happier?
  
   Getting sample content to be usable by others is a pain, and something
   that is one of the last steps people work on.
  
   I think Mozilla moved its tests to MIT to address this.
  
   I have no idea what Apache's policy is.
  
   Unfortunately, I can't find any good examples of this…
  
  
 
 https://github.com/eclipsesource/raspberry-pi-examples/blob/master/com.ecli
  
 
 psesource.iot.photosensor-example/src/com/eclipsesource/iot/photosensor/exa
   mple/Main.java
  
   Has an Eclipse license on a sample, which is probably just as bad.
  
  
 
 http://hg.netbeans.org/main/file/23e994b27837/apisupport.crudsample/crud-sa
   mple-application/CustomerDBAccess/src/demo/Customer.java
  
   Has GPL/CDDL. GPL is clearly useless. I'm not sure CDDL is more helpful
   than Apache.
  
  
  
 
 http://www.contactandcoil.com/software/a-very-fast-tutorial-on-open-source-
   licenses/
  
  
 
 http://mail-archives.apache.org/mod_mbox/cayenne-dev/200710.mbox/%3C62FEC22
   5-fe92-476b-84c1-69869b179...@objectstyle.org%3E
  
   http://apache.org/legal/3party.html#category-a
  
  
 
 http://opendata.stackexchange.com/questions/245/cc-by-vs-mit-or-bsd-license
   s-regarding-re-use
  
  
   https://wiki.creativecommons.org/CC0_FAQ
  
  
   I think we should probably get permission and relicense those files as
   CC-0.
  
   CC-0 isn't in the list that Apache has whitelisted, but I think we
 should
   be able to convince apache that this is the right license for these
 files
   (and similar template files to be used to generate content that a
  consumer
   is supposed to be able to do w/ however they please).
  
   On 12/10/14, 2:02 PM, Brian LeRoux b...@brian.io wrote:
  
   no mistake, but it is a requirement for us to distribute code at
 apache.
   you are free to remove and relicense as you wish.
   
   On Wed, Dec 10, 2014 at 9:49 AM, Martin Sidaway msida...@gmail.com
   wrote:
   
I'm a bit puzzled by the Apache license notice present in the
  following
files after doing cordova create:
   
www/index.html
www/js/index.js
www/css/index.css
   
The trouble is that if I begin my project by extending those files,
 it
seems like the Apache license covers my changes as well as the
  original
template. It also seems like I am saying that my changes are
 licensed
   to
the Apache Software Foundation under one or more contributor license
agreements. And it doesn't seem like the Apache license would allow
  me
   to
remove those notices.
   
So am I right in thinking that if I want to develop software that I
   might
not intend to be Apache-licensed and/or licensed to ASF, I have to
   delete
these 3 files and start from scratch?
   
This sort of thing seems a little inappropriate in a template.
  Basically
what it means is that I have to (1) work out what the template does
  and
which parts I actually need to begin a project, (2) rewrite those
  parts
   by
hand (basic html document structure, meta/viewport tag, etc.) taking
   care
not to resort to copy/paste, (3) gradually realise that the aspects
 of
   my
app that behave inconveniently on certain platforms correspond to
   things I
chose not to copy over from the template.
   
Is there any other way to approach this? Is it a mistake?
   
Thanks.
   
  
  
 

Re: WebView Promise and W3C standards

[Brian LeRoux]

def think we should support those specs in our great and fabled api
audit…had not considered the load order issue

not insurmountable and probably should be a feature/fix for the plugin
loader load order …but also sort of scary… reminds me of script tags hell

on that note: we need to make browserify thing first class. whats the hold
up on that front?

On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org wrote:

 Do we prefer to invent new cordova-specific apis, or prefer to match
 standard browser apis?  When there is no browser spec to match then design
 comes down to aesthetics and personal preference (as you say).  But often
 there is an existing browser spec, and then it comes down to match or
 fork.  I'm in the camp of preferring to match, and was under the assumption
 others here were too.

 Given the upcoming specs mentioned earlier (sockets, file, filesystem,
 permissions, service worker, fetch), seems that fighting the adoption of
 promises in core apis implies opposing the adoption of modern web specs.
  e.g. I'm assuming Andrew was referring to
 http://www.w3.org/TR/battery-status/, since matching that spec *would*
 require promises.


 Now, as I understand, you are not saying you are opposed to adoption of
 promises in Cordova, but that you are simply against the inclusion of a
 polyfill directly inside cordova-js.  I think that a promises-polyfill
 plugin alternative has some technical downsides [1], but they seem not so
 insurmountable that we shouldn't just get passed this debate and do that.

 In my opinion, we should prefer to create a common plugin (at least until
 browserify), since I really hope we don't tell devs to just include their
 own polyfill with each plugin.

 [1]:
 - Can't rely on a polyfill plugin for cordova-js itself.  There are a few
 places where that may have been useful.
 - We don't currently load plugins in an order that respects plugin
 dependencies, so every plugin relying on promises-polyfill will have to
 require() it at runtime before using  and forgetting to do so
 may-or-may-not lead to an error.  Maybe we just fix this in our plugin
 loader.
 - It seems odd that window.Promise will exist depending on which plugins
 you have installed.  While this technically isn't different than with any
 plugin modifying global symbols, it seems odd-er when applied to a
 dependant platform feature.

 -Michal

 On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com wrote:

  Why does battery-status 'require' promises?
 
  I agree that promises are here to stay, but I am unclear why it would be
 a
  good idea to go and change/rewrite/break our apis to use them?
 
  Most of the windows plugins use promises all over the place, the entire
  async windows js api is promise based, but this has zero impact on what
 our
  core-api looks like to a user. The same should apply to any plugin that
  wants to depend on promises, just depend on a promise plugin, which may
 or
  may not add polyfil code to the dom.
 
 
 
 
 
  @purplecabbage
  risingj.com
 
  On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux b...@brian.io wrote:
 
   - no technical benefit (but aesthetics, sure)
   - adds weight (payload and runtime)
   - might interfere with userland polly
  
   -1
  
   On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve agri...@chromium.org
   wrote:
  
One specific spot in core I'd like to use it is to address this TODO
 in
Android's exec bridge:
   
   
  
 
 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263
   
The actual need is for a setImmediate polyfill, but Promise does the
  same
thing (with an extra object creation).
   
On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland 
 iclell...@chromium.org
  
wrote:
   
 On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve 
  agri...@chromium.org
 wrote:

  userland means that plugins won't be able to use them unless
 every
plugin
  also includes a copy of the polyfill within it.
 
  Looking at our core APIs, seems maybe it's just battery-status
 that
will
  require it. Should we have battery-status include the polyfill
  within
 it? I
  hope not. I'd hate to get to where several plugins in my app all
   bundle
 the
  same polyfill.
 

 I believe that Mozilla's new File API, which I think we're planning
  to
 implement, and which should be as core as File is now, is also
  heavily
 promises-based.


 
  If we move to having the entire cordova.js built using browserify
   where
  every plugin gets to contribute to the JS that goes into it -
 yes I
   can
 see
  this solving this use-case as well. But that also seems to me
 like
  a
much
  larger and much more controversial change.
 
  Whether you are for or against promises - they are already here.
  They
  exists natively on most latest mobile webviews, and every vendor
  has
  committed to adding them

Re: WebView Promise and W3C standards

[Brian LeRoux]

we should move browserify to main and drop that insane concat code

its not heavyweight at all. it creates a hash in iife with deps mapped
in…as to why dep mgmt is better than concatenating…I don't think we need to
waste our time talking about that!

On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve agri...@chromium.org wrote:

 There's something implemented behind a --browserify flag, but not sure what
 it does.

 Totally in favour of having CLI / plugman concatenate plugin JS with
 cordova.js, but not convinced that browserify is the right tool for this,
 as it seems quite heavy-weight for just concatenating things. If someone is
 going to resume work on it, would love to hear a summary of what problems
 it's solving (if more than concatenation), and why something more
 light-weight wouldn't be better.

 On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny mmo...@chromium.org wrote:

  We haven't worked on it, also curious.  Anis, perhaps?
 
  On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux b...@brian.io wrote:
 
   def think we should support those specs in our great and fabled api
   audit…had not considered the load order issue
  
   not insurmountable and probably should be a feature/fix for the plugin
   loader load order …but also sort of scary… reminds me of script tags
 hell
  
   on that note: we need to make browserify thing first class. whats the
  hold
   up on that front?
  
   On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny mmo...@chromium.org
   wrote:
  
Do we prefer to invent new cordova-specific apis, or prefer to match
standard browser apis?  When there is no browser spec to match then
   design
comes down to aesthetics and personal preference (as you say).  But
  often
there is an existing browser spec, and then it comes down to match or
fork.  I'm in the camp of preferring to match, and was under the
   assumption
others here were too.
   
Given the upcoming specs mentioned earlier (sockets, file,
 filesystem,
permissions, service worker, fetch), seems that fighting the adoption
  of
promises in core apis implies opposing the adoption of modern web
  specs.
 e.g. I'm assuming Andrew was referring to
http://www.w3.org/TR/battery-status/, since matching that spec
 *would*
require promises.
   
   
Now, as I understand, you are not saying you are opposed to adoption
 of
promises in Cordova, but that you are simply against the inclusion
 of a
polyfill directly inside cordova-js.  I think that a
 promises-polyfill
plugin alternative has some technical downsides [1], but they seem
 not
  so
insurmountable that we shouldn't just get passed this debate and do
  that.
   
In my opinion, we should prefer to create a common plugin (at least
  until
browserify), since I really hope we don't tell devs to just include
  their
own polyfill with each plugin.
   
[1]:
- Can't rely on a polyfill plugin for cordova-js itself.  There are a
  few
places where that may have been useful.
- We don't currently load plugins in an order that respects plugin
dependencies, so every plugin relying on promises-polyfill will have
 to
require() it at runtime before using  and forgetting to do so
may-or-may-not lead to an error.  Maybe we just fix this in our
 plugin
loader.
- It seems odd that window.Promise will exist depending on which
  plugins
you have installed.  While this technically isn't different than with
  any
plugin modifying global symbols, it seems odd-er when applied to a
dependant platform feature.
   
-Michal
   
On Wed, Dec 10, 2014 at 1:56 PM, Jesse purplecabb...@gmail.com
  wrote:
   
 Why does battery-status 'require' promises?

 I agree that promises are here to stay, but I am unclear why it
 would
   be
a
 good idea to go and change/rewrite/break our apis to use them?

 Most of the windows plugins use promises all over the place, the
  entire
 async windows js api is promise based, but this has zero impact on
  what
our
 core-api looks like to a user. The same should apply to any plugin
  that
 wants to depend on promises, just depend on a promise plugin, which
  may
or
 may not add polyfil code to the dom.





 @purplecabbage
 risingj.com

 On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux b...@brian.io wrote:

  - no technical benefit (but aesthetics, sure)
  - adds weight (payload and runtime)
  - might interfere with userland polly
 
  -1
 
  On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve 
  agri...@chromium.org
   
  wrote:
 
   One specific spot in core I'd like to use it is to address this
   TODO
in
   Android's exec bridge:
  
  
 

   
  
 
 https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263
  
   The actual need is for a setImmediate polyfill, but Promise
 does
   the
 same

Re: [iOS 8] WKWebView moving forward

[Brian LeRoux]

so, it appears wkwebview itself is open source [1] …well outside my comfort
zone but feasible we fix these things ourselves?

[1]
https://github.com/WebKit/webkit/blob/0190dd5b8c0272beaa705dbc10863a84a3e6af5e/Source/WebKit2/UIProcess/API/Cocoa/WKWebView.h



On Wed, Dec 10, 2014 at 3:18 PM, Shazron shaz...@gmail.com wrote:

 No dice in iOS 8.2b2 that was released today:

 https://issues.apache.org/jira/browse/CB-7090?focusedCommentId=14241546page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14241546

 On Thu, Nov 20, 2014 at 1:37 PM, Shazron shaz...@gmail.com wrote:
  I updated https://issues.apache.org/jira/browse/CB-8032 with my revised
  approach. I'd like to move on with this as soon as possible.
 
  Let's continue the discussion there.
 
  On Wed, Nov 19, 2014 at 1:14 PM, Homer, Tony tony.ho...@intel.com
 wrote:
 
  Ugh.  Thanks for the additional information, Shazron.
 
  I had previously proposed adding a hook (by which I meant a delegate
  method) to CDVPluginResult (that would be called from -
  (CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal
  message:(id)theMessage) so that LocalWebServer could (blindly) detect
 and
  transform urls.
 
  It seems like it would help with this case, but not be generally useful
  for anything else…
 
  Tony
 
  On 11/19/14, 3:23 PM, Shazron shaz...@gmail.com wrote:
 
  Ideally a general solution like you proposed should work, but I forgot
 to
  mention that in this case, since we are talking about WKWebView, we
 can't
  use NSURLProtocol since it is not supported in that framework [1][2]
  
  The only other general way I can see is to require explicit support in
  plugins, they may have to call something in the
  commandDelegate/viewController to transform a url, that can be set by
  another plugin, in this case LocalWebServer (my revised proposal was a
  'push' this is a 'pull').
  
  
  [1] https://issues.apache.org/jira/browse/CB-7049
  [2] http://www.openradar.me/18492325
  
  On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony tony.ho...@intel.com
  wrote:
  
   If we are just talking about CB-8032, then I can see that this
 approach
  is
   cleaner for the file plugin.
  
   Regarding local web server plugin in general - what about other
 plugins
   such as camera?
   Doesn¹t there need to be a general solution that will provide
   compatibility between local web server plugin and any plugin that
  returns
   a file protocol URL?
  
   Tony
  
   On 11/19/14, 12:19 PM, Shazron shaz...@gmail.com wrote:
  
   I commented on Ian's comment on CB-8032:
   
  
 
   
 https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403p
  a
  
 
  
 ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
  en
   t-14216403
   
   My goal was to have a loose coupling of this functionality (CDVFile
  need
   not know about LocalWebServer at all) -- and Ian's comment of this
  change
   is that would impact all CDVFileSystem instances makes this not an
  ideal
   solution, what if you have two Cordova WebView instances, etc.
   
   My revised proposal requires CDVFileSystem to have a delegate that
 can
  be
   set. Any class can set it to override the nativeURL behaviour, and
   CDVFileSystem will call this method in the delegate if available. It
   achieves the same goal without the potentially undefined behaviour
 of
  an
   Obj-C Category.
   
   The LocalWebServer gets the currently installed File plugin,
enumerates
   all
   available filesystems, and sets this delegate on each, to its own
   implementation.
   
   Tony - I think this is approach is cleaner, and is more
 maintainable.
   
   On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland 
 iclell...@chromium.org
   wrote:
   
On Tue Nov 18 2014 at 2:00:34 PM Jesse purplecabb...@gmail.com
  wrote:
   
 Shaz's solution has less impact and seems more elegant.

 // if ([self respondsToSelector:@selector(nativeFullPath:)]) {

 If no-one ( generically ) has provided the nativeFullPath
 method,
  then
use
 it as is, otherwise call it.
 No need for any (direct) dependency between File + LocalServer.

   
My first instinct, looking at the code, was that it was wrong,
  exactly
because there *is* a dependency. You don't normally add code to a
  base
class to change its behaviour when there is a category defined on
it.
Normally that goes the other way: when you add a category to a
 base
   class,
all of the code that's relevant to that category is *in the
  category*,
   and
the base class needs to know nothing at all about it, including
 its
existence.
   
As I said in the PR, it may be that this really is the cleanest
 and
  best
way to go forward with this; I just wanted to have this discussion
  and
figure it out with the community before committing to any
hard-to-change-later technical debt. It does become an API
 surface,
  and
   we
will have to maintain whatever we 

Re: WebView Promise and W3C standards

[Brian LeRoux]

Minified code is a flat out bad idea and needs to be reverted immediately.
Jesse is right about promises too. Given that native support is immediately
inbound it most certainly should be a plugin. Not core.

I'll reserve debate about it as a lang feature for the drama queens on
hacker news and twitter. ;)

On Fri, Dec 5, 2014 at 11:10 AM, Jesse purplecabb...@gmail.com wrote:

 We would be mandating its support, we have plenty of issues in Jira,
 and this solves none of them.
 ... and minified code? Why? How can I evaluate it?

 My mantra is and will remain Plugins are everything, and everything
 is a plugin
 What is the inconvenience in having a dependency on a promise plugin?
 I don't see the downside, and I think it would be perfect for those
 who want to use it.

 Personally I think we should be pushing the browserify functionality
 in cordova-js, and ripping stuff out, not adding it.


  On Dec 5, 2014, at 9:59 AM, Max Woghiren m...@chromium.org wrote:
 
  I think it's nice to remove that obstacle from in front of plugin
  developers who want to use promises.  If we're going to suggest that
 people
  drop the polyfill in themselves, I don't see the harm in just having it
  there, especially if we don't mandate its use.
 
  Going forward, many/most APIs will use promises; it might get a little
  unwieldy to have a whole bunch of plugins depend on a promise plugin.
 
  The bottom line, for me, is that this doesn't force anyone to use
 promises;
  it's just easy and there for those who want it.
 
  On Fri, Dec 5, 2014 at 12:11 PM, Jesse purplecabb...@gmail.com wrote:
 
  Nice, but please don't add this.
  Anyone who wants or needs this can do what you did, and if I start
 seeing
  promise code throughout Cordova.js I may run.
 
  We should be looking to get rid of Cordova.js entirely, not add more
 deps.
 
  Why not a promise plugin?
 
  Fyi: promises invoke my fight or flight response, and I have only found
  them useful for blocking contribution. That said, they already exist in
  windows8.1 as part of winjs.
 
 
  Sent from mobile
 
  On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org wrote:
 
  I've created a topic branch called promise
  
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/promise
 
  to cordova-js.  It has a commit that adds this ES6 promise polyfill
  https://github.com/jakearchibald/es6-promise (minified) to
 cordova.js
  and
  a simple test to ensure it's found.
 
  That's literally all it is right now—please take a look, though.  Shall
  we
  move forward on this?
 
  On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins br...@bryanhiggins.net
 
  wrote:
 
  BB10 does have a native secure element API. I may be able to dig up
 some
  code which bridges this to JavaScript.
 
 
  On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker ignisvul...@gmail.com
  wrote:
 
  I created https://issues.apache.org/jira/browse/CB-7310 to track
 this.
 
 
  2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:
 
  Good to know. Thanks.
  Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:
 
  Axel Nennker wrote:
  I am interested to implement the secure element API.
  Mozilla is currently implementing it with our help for FFOS but I
  want
  it
  for Android too. Blackberry shouldn't be that difficult using
  JSR177.
 
  BlackBerry classic (which is built around Java) isn't supported by
  Cordova
  and hasn't been for a few releases.
  BlackBerry 10 is built around QNX.
 
  I'm not making a statement about implementability re BB10 (just
 that
  Java
  is irrelevant),
 
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
  l
 
  Is probably where someone would go to start...
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: WebView Promise and W3C standards

[Brian LeRoux]

This has me more convinced it should be a userland library and not even a
plugin. Problem solved! ;)

On Fri, Dec 5, 2014, 12:28 PM Ian Clelland iclell...@chromium.org wrote:

 I have two reasons for not wanting this as a plugin (both of which, I'm
 sure, are entirely subjective)

 The biggest one is just that native support for this really is coming
 quickly, and one day, we'll be able to remove it, because just about every
 platform that we care about will have support built in. Those that don't
 can have the polyfill included as part of *their* cordova.js, and the
 modern platforms can run without it.

 If, by the time we get there, there are a hundred plugins that all depend
 on org.apache.cordova.promise, then we have no choice but to maintain that
 plugin, and we have to tell people to include it, and depend on it, even
 when 95% of devices have native support. On the other hand, when we stop
 supporting iOS 7, if we have included the polyfill in cordova-ios.js, then
 we just remove it, and nothing at all changes for anyone else. Plugin
 developers, application developers, even core Cordova developers who have
 been relying on the polyfill for support, just see everything continue to
 work, and Cordova is lighter as a result.

 The second reason is that I can already see things in Cordova itself that
 I'd like to write in a promise style. I'd love to replace the deviceready
 event with something like

 cordova.deviceReady().then(function() {
 do stuff
 }, function() {
   handle error
 });

 and even

 cordova.exec(Plugin, arguments).then(successCallback).;

 This requires support before plugins load, though. (And I accept that not
 everyone is going to agree with the design)


 On Fri Dec 05 2014 at 3:04:46 PM Max Woghiren m...@chromium.org wrote:

  I can easily change to expanded (non-minified) code; I went with smaller
  size, expecting that people wouldn't be wanting to inspect the promise
  polyfill code.  No big deal.
 
  Earlier in this very thread, people (Jesse included) asserted that it
  should be in core, and Andrew outlined rationale.  I was trying to make
  progress on a task that seemed like a go-ahead and was then left hanging.
  If enough people believe it should be a plugin, then we can certainly go
  that way.  Looking forward to more input.
 
  On Fri, Dec 5, 2014 at 2:10 PM, Jesse purplecabb...@gmail.com wrote:
 
   We would be mandating its support, we have plenty of issues in Jira,
   and this solves none of them.
   ... and minified code? Why? How can I evaluate it?
  
   My mantra is and will remain Plugins are everything, and everything
   is a plugin
   What is the inconvenience in having a dependency on a promise plugin?
   I don't see the downside, and I think it would be perfect for those
   who want to use it.
  
   Personally I think we should be pushing the browserify functionality
   in cordova-js, and ripping stuff out, not adding it.
  
  
On Dec 5, 2014, at 9:59 AM, Max Woghiren m...@chromium.org wrote:
   
I think it's nice to remove that obstacle from in front of plugin
developers who want to use promises.  If we're going to suggest that
   people
drop the polyfill in themselves, I don't see the harm in just having
 it
there, especially if we don't mandate its use.
   
Going forward, many/most APIs will use promises; it might get a
 little
unwieldy to have a whole bunch of plugins depend on a promise plugin.
   
The bottom line, for me, is that this doesn't force anyone to use
   promises;
it's just easy and there for those who want it.
   
On Fri, Dec 5, 2014 at 12:11 PM, Jesse purplecabb...@gmail.com
  wrote:
   
Nice, but please don't add this.
Anyone who wants or needs this can do what you did, and if I start
   seeing
promise code throughout Cordova.js I may run.
   
We should be looking to get rid of Cordova.js entirely, not add more
   deps.
   
Why not a promise plugin?
   
Fyi: promises invoke my fight or flight response, and I have only
  found
them useful for blocking contribution. That said, they already exist
  in
windows8.1 as part of winjs.
   
   
Sent from mobile
   
On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org
 wrote:
   
I've created a topic branch called promise

   
   https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=
  shortlog;h=refs/heads/promise
   
to cordova-js.  It has a commit that adds this ES6 promise polyfill
https://github.com/jakearchibald/es6-promise (minified) to
   cordova.js
and
a simple test to ensure it's found.
   
That's literally all it is right now—please take a look, though.
  Shall
we
move forward on this?
   
On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins 
  br...@bryanhiggins.net
   
wrote:
   
BB10 does have a native secure element API. I may be able to dig
 up
   some
code which bridges this to JavaScript.
   
   
On Thu, Aug 

Re: For Review: Dec 2014 - Apache Cordova Board Report Draft

[Brian LeRoux]

Man that is a tonne of work to compile. Thx Shaz (again)

Looks good from here.

On Mon, Dec 1, 2014, 4:00 PM Shazron shaz...@gmail.com wrote:

 It's that time of the year again.

 Here's the draft:
 https://github.com/cordova/apache-board-reports/blob/
 master/2014/2014-12.md

 Send pull requests, etc if there are changes needed. Deadline to send
 this in is Dec 10th.


 We're on the downward trend for commits and dev@ activity this
 quarter. However we had 60 releases vs 44 last quarter. For npm
 cordova downloads we had a 100K increase from last quarter.

 https://github.com/cordova/apache-board-reports/blob/
 master/2014/stats.json

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Notification in dialog plugin

[Brian LeRoux]

ya this is legacy pain; the source formerly known as phonegap predates
push/local notifications!

used to be vibrate, flash indicator lights (remember those on
blackberries?) and beep (also lol)

we named the plugin repo cordova-plugin-dialogue (and moved vibrate out)
b/c that seemed more appropriate for alert, confirm and friends.

since everything is independently revision-ed in plugins now I say:
refactor with impunity.

On Wed, Nov 26, 2014 at 7:28 AM, Piotr Zalewa pzal...@mozilla.com wrote:

 Hi

 I came across an issue in writing a Notification support in Cordova.
 Dialogs plugin uses Notification for a classy object. I think it should be
 called Dialog or similar and not take the Notification. I actually think
 the navigator.notifications is wrong name either, that however might hold a
 bigger impact on users currently using it.

 Should we change this?
 --
 Piotr Zalewa
 Mozilla

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Introduction

[Brian LeRoux]

wow really nice stuff Daniel. xplatform desktop plugins to an embedded
chome browser is hella cool! [1]

let us know how we can help you

(first glance appears we could help by impl 'platform scripts' [2] which
puts the project on the path to the cli and being an 'official' platform)

[1]
https://github.com/hsimpson/cordova-cef/blob/master/src/common/cordovaplugin.h
[2] https://github.com/apache/cordova-ios/tree/master/bin


On Tue, Nov 25, 2014 at 6:07 AM, Toplak Daniel d.top...@cadenas.de wrote:

 Hi,

 at the moment the only work was done on the windows component, but the
 amount should be less for OSX and Linux to get the core running. Chromium
 Embedded Framework is also available on OSX and Linux. And the core
 (JS-Bridge, Plugin Management, Preferences) are nearly platform independent.

 To get this a first class Cordova platform many things have to be done
 (whitelist handling, project management, and creation via templates, CLI
 integration, testings, etc.). Also the current core was ported from around
 Cordova 3.0's iOS and Android version and is a bit outdated, it should
 respect the features/interfaces from the current Cordova 4.x branches.

 Daniel

 -Ursprüngliche Nachricht-
 Von: Ian Clelland [mailto:iclell...@chromium.org]
 Gesendet: Dienstag, 25. November 2014 14:40
 An: dev@cordova.apache.org
 Betreff: Re: Introduction

 Welcome, Daniel!

 That's a really interesting project -- I'm looking forward to trying that
 out. How much work (if any) has gone in to the OSX or Linux components?

 Do you see this eventually becoming a first-class Cordova platform, or do
 you have different plans for it?

 Ian

 On Tue Nov 25 2014 at 1:47:27 AM Toplak Daniel d.top...@cadenas.de
 wrote:

  Hi,
 
  my name is Daniel Toplak, I am the team leader of the mobile
  development department of CADENAS GmbH, Augsburg, Germany,
 http://www.cadenas.de.
  We are using Cordova for our mobile app development since phonegap 2.6.
  We have signed the CCLA, and created an account on Jira.
 
  I have a cordova implementation based on CEF (Chromium Embedded
  Framework) which is not yet production ready, but more a proof of
 concept:
  https://github.com/hsimpson/cordova-cef (my private github account)
 
  I'm following the dev list long ago and happy to contribute to a great
  project.
 
 
  Mit freundlichen Grüßen / Best regards
 
  CADENAS GmbH
  Head of Mobile Development
  Daniel Toplak
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Summarizing thoughts on cordova-browser vs Ripple

[Brian LeRoux]

I'm less interested in copying work being done faster/better in the browser
devtools. Certainly some UI abstractions are helpful (map controls,
acceleromter scrubbing widget, etc) but the returns for dev time are
diminishing for the effort to author/maintain. Esp bad considering we'd
have to pick UI paradigms and enforce them somehow.

For my two pennies, providing an abstraction that allows authoring time
convenience of using browser with an eventual goal for open web publishing
would be the best architecture (and strategy) for Cordova to pursue.

On Tue, Nov 18, 2014 at 9:12 AM, Michal Mocny mmo...@chromium.org wrote:

 On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden rayca...@adobe.com wrote:

 
  
   On 11/15/14, 2:17 PM, Michal Mocny mmo...@chromium.org wrote:
  
 
  Not at all.  What is it you think we are proposing?  I'm merely
  suggesting
  that the cordova-browser camera plugin implementation shouldn't *also*
  come
  with a DOM component that sits over top of your application to
 manipulate
  the camera.  The existing BAAP camera implementation is great as
 currently
  implemented, and wouldn't change.
  
  Another example would better illustrate the difference: BAAP geolocation
  shim I believe should just use the browser geolocation api, or return a
  single fixed location if that isn't available.  It needn't support
  programmatically / UI for manipulating custom location, which Ripple
  geolocation does.
 
  I’m with you on that - but I think that is an example that works well w/o
  UI and other plugins may not. Let’s consider contacts, specifically
  pickContact. I *would* be ok with a UI of some sort, perhaps just 3
 simple
  contacts in a list, that that user can select. In theory it could also
  just automatically fire contactSuccess, but my point is that I’m not
  opposed to it providing a bit of UI as well.
 
 
  As an example, I¹ve got an app now which uses barcode scanning for one
   small part. By adding the Browser platform to the plugin, I am able to
  do
   all of my work in the browser now and fake a barcode when I need it.
  That
   is a problem that - imo - is much more valuable than supporting
 browser
  as
   a destination of my app.
  
  
  If you just want to return a single fixed barcode, I agree BAAP should
 do
  this.  If you want to be able to customize the barcode at runtime, with
 a
  simple UI that is automatically injected into your page as part of the
  runtime, then I think that is a task for Ripple (or other emulators).
 
 
  So I think this is the crux of our disagreement then. :) Right now the
  plugin (and I wrote this, so I may be biased ;) uses a prompt so you can
  enter a code. My thinking there was if you didn’t care, you would type 1
  and hit enter, but if you were passing the bar code to some service, you
  could paste something in. To me, that’s more useful then just using a
 hard
  coded value you can’t tweak. I think that usefulness outweighs the
  potential ‘loss’ of being able to run this as a real web app.
 

 Fair enough.  Sounds like you want some of what I've proposed Ripple could
 offer, but are concerned that Ripple won't be a viable/sustainable choice
 for you.  To be honest, I share that concern.

 For the barcode scanning example, I think a popup with an input box is
 fine, even for prod, so long as the popup is presented as if to a user and
 not as if to a developer.  Hopefully we can improve it to also offer an
 input type=image, or to use the webcam (I haven't looked, not sure if it
 does this yet).

 If we really want separate dev mode and prod mode for a given plugin,
 perhaps we can just add an api for toggle this.  I just hope to set the
 precedent that the default isn't *just* for developer debugging.

 -Michal

Re: [mobile-spec] consistency and reliability

[Brian LeRoux]

- ya sorry for being confusing TAP is a protocol, that part is neat but I
don't really care
- tap/tape are libs for testing that emit TAP results: this is nice
- tap/tape are NOT global runners so you have to explicitly call them and
load them…this is really nice

the problem w/ jasmine, or one of them anyhow, is the global nature and
magic injection of things

On Mon, Nov 3, 2014 at 1:09 PM, Michal Mocny mmo...@chromium.org wrote:

 I thought tap was just a format for reporting test results?  I think the
 problem is that we have some poorly written tests and the framework is not
 recovering well.  Any reporting format is orthogonal (unless perhaps the
 bug is specific to the jasmine-html reporter, but I'm not sure there is any
 evidence of that).

 That said, writing well behaving async tests can be difficult, so I would
 hope any test framework would do better to defend against that.  Perhaps
 tape is better.  During the big test migration I evaluated mocha (BDD
 style) as a replacement for jasmine-2.0 since the test definition format is
 really similar, but it had a silly limitation that made porting some tests
 difficult: no support for async describe() blocks, and could not nest it()
 blocks as a workaround.  I don't recall the specific plugin(s) which had an
 issue with this.

 -Michal

 On Mon, Nov 3, 2014 at 3:05 PM, Marcel Kinard cmarc...@gmail.com wrote:

  I haven't seen tap/tape until Brian mentioned it here. From a quick read,
  it looks like a port of the tests from Jasmine to tape will be required
 on
  the runner side. Then we can use whatever reporting we want that can
  consume tap. So if I understand it correctly, the existing tests aren't
  throwaway, but getting off Jasmine certainly won't be free. Assuming that
  tape is less brittle and not substantially less functional that Jasmine,
  could be a net win. Doing the port looks like it will take a fair amount
 of
  crank-turning.
 
  On Oct 30, 2014, at 8:09 PM, Brian LeRoux b...@brian.io wrote:
 
   Nope.
  
   On Thu, Oct 30, 2014, 5:04 PM Jesse purplecabb...@gmail.com wrote:
  
   I would much rather we fix things, than continually rewrite + discard,
   which seems to be the norm these days.
   tape/tap would require us to throw away thousands of jasmine2 based
  tests
   wouldn't it?
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

Re: [mobile-spec] consistency and reliability

[Brian LeRoux]

tape (and or tap) has no globals and simple / shallow callback solution
which fixes that

we will have fresh intern blood to sacrifice to the test lib gods alter
soon..

On Thu, Oct 30, 2014, 4:10 PM Michal Mocny mmo...@chromium.org wrote:

 I've seen that in the past and it usually happens due to misuse of jasmine,
 which seems unfortunately quite brittle.  Specifically, if done() isn't
 called, or an async event fires after a test has already failed / timed out
 and calls done(), or registers new tests with it() etc, weird things will
 happen.

 Usually its a sign that a test is not handling failures appropriately, but
 it is a bit unfortunate that jasmine is so brittle.

 -Michal

 On Thu, Oct 30, 2014 at 6:10 PM, Toda, Shingo shin...@fast.au.fujitsu.com
 
 wrote:

  This is exactly what I got too.
 
  Regards,
  Shingo
 
  From: Shazron [mailto:shaz...@gmail.com]
  Sent: Friday, October 31, 2014 9:02 AM
  To: dev@cordova.apache.org
  Cc: Toda, Shingo
  Subject: Re: [mobile-spec] consistency and reliability
 
  Seems to be exactly what I am seeing.
  Here's the image as a link: http://i.imgur.com/n6ST1Kd.png?1
 
  On Thu, Oct 30, 2014 at 2:57 PM, Toda, Shingo 
 shin...@fast.au.fujitsu.com
  mailto:shin...@fast.au.fujitsu.com wrote:
  Hi Shazron
 
  Our team are running mobilespec for Android, iOS and Windows. I cannot
 see
  the attachment but we also have been seeing what you’ve gotten since new
  style mobilespec was introduced. It seems that each plugin test run works
  fine but if all tests get run at once I am likely to get more than one
  report in a run reporting that there are a number of specs like 900 specs
  (I don’t think specs are so much).
 
  I noticed that some of the specs were called more than once when I got
  multiple reports. I usually disable FileTransfer, Globalization and Media
  specs at first then run test for them individually because I saw some of
  those tests got called more than once. This could be just my case so it
  might not be yours.
 
  Regards,
  Shingo
 
  From: Shazron [mailto:shaz...@gmail.commailto:shaz...@gmail.com]
  Sent: Friday, October 31, 2014 7:54 AM
  To: dev@cordova.apache.orgmailto:dev@cordova.apache.org
  Subject: [mobile-spec] consistency and reliability
 
 
  `cordova-mobile-spec/createmobilespec/createmobilespec.js --ios
  --globalplugins`
 
  Has anyone gotten mobile-spec to work consistently? I get wildly
 different
  results on each run. Sometimes there is more than one report in a run.
 See:
 
  [Inline image 1]
 
 

Re: [mobile-spec] consistency and reliability

[Brian LeRoux]

Nope.

On Thu, Oct 30, 2014, 5:04 PM Jesse purplecabb...@gmail.com wrote:

 I would much rather we fix things, than continually rewrite + discard,
 which seems to be the norm these days.
 tape/tap would require us to throw away thousands of jasmine2 based tests
 wouldn't it?


 @purplecabbage
 risingj.com

 On Thu, Oct 30, 2014 at 4:44 PM, Brian LeRoux b...@brian.io wrote:

  tape (and or tap) has no globals and simple / shallow callback solution
  which fixes that
 
  we will have fresh intern blood to sacrifice to the test lib gods alter
  soon..
 
  On Thu, Oct 30, 2014, 4:10 PM Michal Mocny mmo...@chromium.org wrote:
 
   I've seen that in the past and it usually happens due to misuse of
  jasmine,
   which seems unfortunately quite brittle.  Specifically, if done() isn't
   called, or an async event fires after a test has already failed / timed
  out
   and calls done(), or registers new tests with it() etc, weird things
 will
   happen.
  
   Usually its a sign that a test is not handling failures appropriately,
  but
   it is a bit unfortunate that jasmine is so brittle.
  
   -Michal
  
   On Thu, Oct 30, 2014 at 6:10 PM, Toda, Shingo 
  shin...@fast.au.fujitsu.com
   
   wrote:
  
This is exactly what I got too.
   
Regards,
Shingo
   
From: Shazron [mailto:shaz...@gmail.com]
Sent: Friday, October 31, 2014 9:02 AM
To: dev@cordova.apache.org
Cc: Toda, Shingo
Subject: Re: [mobile-spec] consistency and reliability
   
Seems to be exactly what I am seeing.
Here's the image as a link: http://i.imgur.com/n6ST1Kd.png?1
   
On Thu, Oct 30, 2014 at 2:57 PM, Toda, Shingo 
   shin...@fast.au.fujitsu.com
mailto:shin...@fast.au.fujitsu.com wrote:
Hi Shazron
   
Our team are running mobilespec for Android, iOS and Windows. I
 cannot
   see
the attachment but we also have been seeing what you’ve gotten since
  new
style mobilespec was introduced. It seems that each plugin test run
  works
fine but if all tests get run at once I am likely to get more than
 one
report in a run reporting that there are a number of specs like 900
  specs
(I don’t think specs are so much).
   
I noticed that some of the specs were called more than once when I
 got
multiple reports. I usually disable FileTransfer, Globalization and
  Media
specs at first then run test for them individually because I saw some
  of
those tests got called more than once. This could be just my case so
 it
might not be yours.
   
Regards,
Shingo
   
From: Shazron [mailto:shaz...@gmail.commailto:shaz...@gmail.com]
Sent: Friday, October 31, 2014 7:54 AM
To: dev@cordova.apache.orgmailto:dev@cordova.apache.org
Subject: [mobile-spec] consistency and reliability
   
   
`cordova-mobile-spec/createmobilespec/createmobilespec.js --ios
--globalplugins`
   
Has anyone gotten mobile-spec to work consistently? I get wildly
   different
results on each run. Sometimes there is more than one report in a
 run.
   See:
   
[Inline image 1]
   
   
  
 

Re: Plugman issues/questions

[Brian LeRoux]

thats def a bug John / pls file!

On Wed, Oct 29, 2014 at 5:52 AM, John M. Wargo jwarg...@gmail.com wrote:

 I'm playing around with plugman in Cordova 4.0 and have found some issues
 and have some questions.

 First of all, the docs are incorrect and I've filed a ticket:
 https://issues.apache.org/jira/browse/CB-7894.  The example for adding a
 plugin is missing the install switch.:

 $ plugman -platform ios|amazon-fireos|android|blackberry10|wp8
 --project directory --plugin name|url|path [--plugins_dir directory]
 [--www directory] [-variable name=value [--variable name=value
 ...]]

 It should be:

 $ plugman install -platform ios|amazon-fireos|android|blackberry10|wp8
 --project directory --plugin name|url|path[--plugins_dir directory]
 [--www directory] [-variable name=value [--variable name=value
 ...]]

 The docs also say that the switch for uninstall is --uninstall, but in
 my testing it's actually uninstall  - I've created a ticket for this:
 https://issues.apache.org/jira/browse/CB-7895.

 The docs say to use the platform scripts to create a plugman project, but
 when I follow the links to the download, there's no download for Cordova
 4.0. When will that be published?

 When I unpublish my plugin, it says it's unpublished, but the entry is
 still there in the registry. Should I submit a ticket for this?

 I can't find any information on what the plugman owner command does. When
 I execute it, I get an error:

 C:\Users\jwargo\dev\mypluginplugman owner ls
 ENOENT, open 'C:\Users\jwargo\dev\myplugin\package.json'

 I can't find anything in the docs that tells me I should be creating a
 package.json. Should I be?

 I created one using npm init. Then, when I issue a plugman owner ls I get
 the following error:

 404 Not Found: myplugin

 Can someone explain to me how this is supposed to work? I can't seem to
 find any documentation on this command.

 Regarding the registry, it doesn't explain anywhere how to set the
 description for the plugin - I'm assuming it's through a readme.md file.
 I also don't see anywhere I can login to the registry site and edit my
 entry. I'm assuming also that keywords are set through the package.json
 file?

 --
 John M. Wargo
 @johnwargo http://twitter.com/johnwargo
 www.johnwargo.com http://www.johnwargo.com
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 --

Re: adding push notifications to core plugins

[Brian LeRoux]

for me its about acknowledging the importance of push notifications to the
platform and making it a first class citizen


On Mon, Oct 20, 2014 at 5:13 AM, Gorkem Ercan gorkem.er...@gmail.com
wrote:

 On Thu, Oct 16, 2014 at 03:24:26PM -0700, Jesse wrote:
  Core, or no core, the plugin already exists:
  https://github.com/phonegap-build/PushPlugin/
  It works on iOS, Android, BB10, WP8, Windows8, and Amazon Fire OS.
 
  In my mind, the fact that every device uses it's own messaging service
  makes this a non-starter. At least for moving to core, and/or adding to
 the
  API.
 

 What is the expected benefit of moving a plugin this much mature to
 core plugins?


 
  @purplecabbage
  risingj.com
 
  On Thu, Oct 16, 2014 at 1:41 PM, Joe Bowser bows...@gmail.com wrote:
 
   I bet you that the Android Camera is more terrible than the iOS camera.
  
   The big problem with a lot of the plugins is that we make promises
 that we
   can't keep.  For example, the Android camera only supports JPG, but our
   docs say that you can take PNG photos, which not only makes very little
   sense, but isn't possible with the current code without a really big
   refactor. There's also the whole memory restriction problem that has
   creeped its ugly head with the Moto G and Moto E, which are lower end
   devices with a lot of users.  The Battery Spec is another example,
 where
   the current Android implemntation is unusable, and the W3C Proposal is
   absolute garbage and unimplementable.
  
   I don't want any more core plugins until we finally do our long
 promised,
   but forever pushed forward API audit.  I know that a push notifications
   plugin is super tempting, but this is like us adopting another puppy
 when
   we have a dead hamster, fish and turtle in our room stinking up the
 place.
  
   On Thu, Oct 16, 2014 at 1:35 PM, Shazron shaz...@gmail.com wrote:
  
The Camera (esp iOS) is terrible IMO, we should replace with some
   standard
API, like we've talked about before (not sure which spec).
   
On Thu, Oct 16, 2014 at 1:33 PM, Brian LeRoux b...@brian.io wrote:
   
 I'm all for code removal. Which plugins tho?


 On Thu, Oct 16, 2014 at 1:23 PM, Joe Bowser bows...@gmail.com
 wrote:

  Do we need more core plugins? We're already pretty terrible at
supporting
  what we have on our plate now.  I would rather we have less core
plugins
  than more.
 
  On Thu, Oct 16, 2014 at 12:27 PM, Jesse purplecabb...@gmail.com
 
wrote:
 
   This one supports everything:
  
   https://github.com/phonegap-build/PushPlugin/blob/master/plugin.xml
  
   and it is MIT
  
   @purplecabbage
   risingj.com
  
   On Thu, Oct 16, 2014 at 12:10 PM, Lorin Beer 
 lorin.b...@gmail.com
   
  wrote:
  
I've been asked about this from multiple sources over the
 last
   few
  weeks.
Given how important push notifications are for mobile
 projects, a
 core
   push
notification plugin would be a great addition and another
   argument
 for
   why
you should use cordova.
   
On Thu, Oct 16, 2014 at 11:58 AM, Brian LeRoux b...@brian.io
   wrote:
   
 just was discussing w/ Shaz and Jesse…thoughts?

   
  
 

   
  

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: PhoneGap day

[Brian LeRoux]

\o/
On Oct 18, 2014 10:53 AM, Ken Wallis kwal...@blackberry.com wrote:

 I'll be there.

 Sent from my BlackBerry 10 smartphone.
   Original Message
 From: Piotr Zalewa
 Sent: Saturday, October 18, 2014 10:18 AM
 To: dev@cordova.apache.org
 Reply To: dev@cordova.apache.org
 Cc: Don Coleman
 Subject: Re: PhoneGap day


 I'll be there a well

 Dnia Sat Oct 18 04:31:22 2014 Don Coleman pisze:
  I'll be there
 
 
 
  On Oct 17, 2014, at 9:29 PM, tommy-carlos williams to...@devgeeks.org
 wrote:
 
  I will certainly be there.
 
 
 
 
  On 18 October 2014 at 12:08:49, Jesse (purplecabb...@gmail.com) wrote:
 
  Who all is coming?
 
  I will be there for my first ever phonegap day. I've only been working
 with
  phonegap since 2008 ...
 
  Cheers,
  Jesse
 
 
  @purplecabbage
  risingj.com
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 

 --
 Piotr Zalewa
 Mozilla

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

RE: Adding node-webkit as a platform

[Brian LeRoux]

I echo the (classic) maintainer fear of abandonment (remember Symbian? Me
either)

...but if ppl want to step up and own the platform this will be very well
received. There is a low cost to finding out. So let's see where this goes.
On Oct 18, 2014 12:10 PM, Maxime LUCE max...@touchify.co wrote:

 I'm really happy I'm not the only one to want this great platform
 integrated into cordova.
 If enough of us can be involved, we will be able to carry out this project.

 Since you asked me to not wait to start my research.
 Here are the results of my first analysis :

 Firstly our work will be simplified by three things :
 - We can reuse a lot of code from Browser platform.
 - Chromium implement many features natively, we only have to align these
 with our specs.
 - We have access to nodejs which is really easy to use and can perform a
 lot of tasks.

 Below, I will detail the work to be done by repository.

 # Work on cordova-js :
 - exec: same as Browser platform
 - platform: we should isolate nodejs's require function
 -- window.nodeRequire = window.require;
 -- window.require = null;

 # Work on cordova-lib / cordova (cordova-cli) :
 - parser:   We can reuse browser_parser.js
 We have to create node-webkit specific package.json using
 update_from_config function
 - platforms:Just add the platform into platforms.js

 # Work on cordova-lib / plugman (plugman) :
 - platforms:Same as browser

 # Work on node-webkit platform
 - We can start using the cordova-browser platform
 - template: replace manifest.webapp by package.json
 - scripts:
 - clean: no changes
 - version: no changes
 - run: run nw using www folder as startup path
 - build: zip www folder to app.nw
 - create: copy template dir
   download node-webkit binaries based on platform and
 node-version
 - update: copy cordova-js
 download new node-webkit binaries
 - check_reqs: node-version = 0.10

 Now I will details work to be done on plugins :

 # Battery-Status
 We can use the node-battery module (
 https://github.com/leon-vv/node-battery)

 # Camera
 We can use native function  getUserMedia

 # Console
 No need as Chromium console is already great !

 # Contacts
 VCARD parser ?

 # Device
 Platform:   navigator.platform
 Model:  node-webkit /  + win32|mac|linux + (x64)
 Version:
 https://github.com/rogerwang/node-webkit/wiki/Get-version-of-node-webkit-in-app
 Cordova:browser.cordovaVersion
 Uuid:   Stored in DOM Storage

 # Accelerometer / Compass
 http://www.html5rocks.com/en/tutorials/device/orientation/

 # Dialogs
 Custom Solution : HTML5 / Design adapted on  each platforms ?
 Beep: https://github.com/feross/beepbeep

 # FileSystem
 Two choices :
 - Use native FileSystem API implemented in Chromium
 - Use node fs module

 # File Transfer
 - Use node request module

 # Geolocation
 Already implemented in Chromium

 # Globalization
 Use navigator + custom solution

 # InAppBrowser
 https://github.com/rogerwang/node-webkit/wiki/Mini-browser-in-iframe

 # Media
 HTML 5 Audio / Video Wrapper

 # Media Capture
 We can use native function  getUserMedia

 # Network Information
 Same as Browser implementation

 # Splash screen
 Custom solution using :
 https://github.com/rogerwang/node-webkit/wiki/Window#openurl-options

 # Vibration
 Already implemented natively

 # Status Bar
 Can be used to control toolbar visibility.
 But don't think there is a real need since toolbar need a specific
 implementation.

 Wow !
 I think it's a good global view to understand the work to be done to
 implement node-webkit into cordova.

 Let me know your thoughts.

 Thanks !
 
 Maxime LUCE
 Touchify - CEO
 +33 6 28 60 72 34 | skype: maximeluce
 max...@touchify.co | http://touchify.co

 -Message d'origine-
 De : Tommy Williams [mailto:to...@devgeeks.org]
 Envoyé : samedi 18 octobre 2014 04:22
 À : dev@cordova.apache.org
 Objet : Re: Adding node-webkit as a platform

 Might be able to help with this.

 We are pretty invested in Node-Webkit.
 On 18 Oct 2014 13:00, Brian LeRoux b...@brian.io wrote:

  +1 to swarm dev ... That is our (not only) advantage being at Apache
  On Oct 17, 2014 6:33 PM, Jesse purplecabb...@gmail.com wrote:
 
   No, don't wait for me ... swarm.
  
   @purplecabbage
   risingj.com
  
   On Fri, Oct 17, 2014 at 6:24 PM, Maxime LUCE max...@touchify.co
 wrote:
  
Ok I wait for your report to start my researches.
   
   
Maxime LUCE
Touchify, CEO
   
+33 6 28 60 72 34 | skype: maximeluce
max...@touchify.co | http://touchify.co
   
   
-Message d'origine-
De : Jesse [mailto:purplecabb...@gmail.com] Envoyé : samedi 18
octobre 2014 03:06 À : dev@cordova.apache.org Objet : Re: Adding
node-webkit as a platform
   
Yeah, I think it would be awesome if we could

Re: Adding node-webkit as a platform

[Brian LeRoux]

+1 to swarm dev ... That is our (not only) advantage being at Apache
On Oct 17, 2014 6:33 PM, Jesse purplecabb...@gmail.com wrote:

 No, don't wait for me ... swarm.

 @purplecabbage
 risingj.com

 On Fri, Oct 17, 2014 at 6:24 PM, Maxime LUCE max...@touchify.co wrote:

  Ok I wait for your report to start my researches.
 
 
  Maxime LUCE
  Touchify, CEO
 
  +33 6 28 60 72 34 | skype: maximeluce
  max...@touchify.co | http://touchify.co
 
 
  -Message d'origine-
  De : Jesse [mailto:purplecabb...@gmail.com]
  Envoyé : samedi 18 octobre 2014 03:06
  À : dev@cordova.apache.org
  Objet : Re: Adding node-webkit as a platform
 
  Yeah, I think it would be awesome if we could decouple cordova-cli and
  cordova-plugman from each and every platform, but given the recent
  version+pinning discussions, this may be hard to get through.
 
  I will play try to play with it a bit (over the weekend) and report back.
 
  @purplecabbage
  risingj.com
 
  On Fri, Oct 17, 2014 at 5:55 PM, Maxime LUCE max...@touchify.co wrote:
 
   I understand your thoughts...
   The main problem if we create a separate platform is that we can't add
   support for plugins (or I don't know how ?).
  
   We could try to simplify the process to work with custom platform
   outside the main distribution.
  
  
  
   Maxime LUCE
   Touchify, CEO
  
   +33 6 28 60 72 34 | skype: maximeluce
   max...@touchify.co | http://touchify.co
  
  
   -Message d'origine-
   De : Jesse [mailto:purplecabb...@gmail.com] Envoyé : samedi 18 octobre
   2014 02:43 À : dev@cordova.apache.org Objet : Re: Adding node-webkit
   as a platform
  
   official?
   If you want to do it, or anyone else does, then they should go for it.
   Here's my random thoughts ...
   I think it would be awesome, but we currently all appear to have way
   more work than we can accomplish. The issue list in JIRA is out of
   control, and we seem to be losing ground.
   What happened to 'sugar' as a platform? Their pull requests are
   sitting and waiting ... [1] Tizen [2][3] ??
   Browser as a platform took months, and is only finally in, although no
   one knows about it.
   Adding a platform currently affects cordova-lib/cli/js + plugman +
   every core plugin ... having more platforms may not be better,
   especially if they aren't maintained.
  
  
   [1] https://github.com/apache/cordova-lib/pull/98
   [2] https://github.com/apache/cordova-lib/pull/47
   [3] https://github.com/apache/cordova-lib/pull/16
  
  
   @purplecabbage
   risingj.com
  
   On Fri, Oct 17, 2014 at 5:03 PM, Dick Van den Brink 
   d_vandenbr...@outlook.com wrote:
  
Would be awesome, I created this myself using CefClient (without
cordova-plugins) and for Windows only. Official support with
node-webkit would be a cool idea!
   
   
   
   
   
   
Verzonden met Windows Mail
   
   
   
   
   
Van: Maxime LUCE
Verzonden: ‎zaterdag‎ ‎18‎ ‎oktober‎ ‎2014 ‎01‎:‎32
Aan: dev@cordova.apache.org
   
   
   
   
   
Hi everyone,
   
I want to start again a debate about adding node-webkit as a
platform for cordova.
It will allow developers to target Windows (Desktop), Mac OS X and
  Linux.
   
It could also be a way to debug complex applications without any
simulators.
   
I really want to target this platform and for now I need to create a
separate project.
Having all my applications in the same project (Cordova) would be a
great productivity improvement.
I think I'm not the only cordova users who want to target Destkop
platforms.
   
What do you think ?
   

Maxime LUCE
Touchify - CEO
+33 6 28 60 72 34 | skype: maximeluce
max...@touchify.co | http://touchify.co
   
  
 

adding push notifications to core plugins

[Brian LeRoux]

just was discussing w/ Shaz and Jesse…thoughts?

Re: adding push notifications to core plugins

[Brian LeRoux]

I'm all for code removal. Which plugins tho?


On Thu, Oct 16, 2014 at 1:23 PM, Joe Bowser bows...@gmail.com wrote:

 Do we need more core plugins? We're already pretty terrible at supporting
 what we have on our plate now.  I would rather we have less core plugins
 than more.

 On Thu, Oct 16, 2014 at 12:27 PM, Jesse purplecabb...@gmail.com wrote:

  This one supports everything:
  https://github.com/phonegap-build/PushPlugin/blob/master/plugin.xml
 
  and it is MIT
 
  @purplecabbage
  risingj.com
 
  On Thu, Oct 16, 2014 at 12:10 PM, Lorin Beer lorin.b...@gmail.com
 wrote:
 
   I've been asked about this from multiple sources over the last few
 weeks.
   Given how important push notifications are for mobile projects, a core
  push
   notification plugin would be a great addition and another argument for
  why
   you should use cordova.
  
   On Thu, Oct 16, 2014 at 11:58 AM, Brian LeRoux b...@brian.io wrote:
  
just was discussing w/ Shaz and Jesse…thoughts?
   
  
 

Re: adding push notifications to core plugins

[Brian LeRoux]

it is very easily arguable that notifications are important to mobile, and
important enough that we should look at ensuring Cordova as a platform
supports them well

but agreed we need to pull up our socks on the older stuff, and maybe do
some housecleaning

On Thu, Oct 16, 2014 at 3:24 PM, Jesse purplecabb...@gmail.com wrote:

 Core, or no core, the plugin already exists:
 https://github.com/phonegap-build/PushPlugin/
 It works on iOS, Android, BB10, WP8, Windows8, and Amazon Fire OS.

 In my mind, the fact that every device uses it's own messaging service
 makes this a non-starter. At least for moving to core, and/or adding to the
 API.


 @purplecabbage
 risingj.com

 On Thu, Oct 16, 2014 at 1:41 PM, Joe Bowser bows...@gmail.com wrote:

  I bet you that the Android Camera is more terrible than the iOS camera.
 
  The big problem with a lot of the plugins is that we make promises that
 we
  can't keep.  For example, the Android camera only supports JPG, but our
  docs say that you can take PNG photos, which not only makes very little
  sense, but isn't possible with the current code without a really big
  refactor. There's also the whole memory restriction problem that has
  creeped its ugly head with the Moto G and Moto E, which are lower end
  devices with a lot of users.  The Battery Spec is another example, where
  the current Android implemntation is unusable, and the W3C Proposal is
  absolute garbage and unimplementable.
 
  I don't want any more core plugins until we finally do our long promised,
  but forever pushed forward API audit.  I know that a push notifications
  plugin is super tempting, but this is like us adopting another puppy when
  we have a dead hamster, fish and turtle in our room stinking up the
 place.
 
  On Thu, Oct 16, 2014 at 1:35 PM, Shazron shaz...@gmail.com wrote:
 
   The Camera (esp iOS) is terrible IMO, we should replace with some
  standard
   API, like we've talked about before (not sure which spec).
  
   On Thu, Oct 16, 2014 at 1:33 PM, Brian LeRoux b...@brian.io wrote:
  
I'm all for code removal. Which plugins tho?
   
   
On Thu, Oct 16, 2014 at 1:23 PM, Joe Bowser bows...@gmail.com
 wrote:
   
 Do we need more core plugins? We're already pretty terrible at
   supporting
 what we have on our plate now.  I would rather we have less core
   plugins
 than more.

 On Thu, Oct 16, 2014 at 12:27 PM, Jesse purplecabb...@gmail.com
   wrote:

  This one supports everything:
 
  https://github.com/phonegap-build/PushPlugin/blob/master/plugin.xml
 
  and it is MIT
 
  @purplecabbage
  risingj.com
 
  On Thu, Oct 16, 2014 at 12:10 PM, Lorin Beer 
 lorin.b...@gmail.com
  
 wrote:
 
   I've been asked about this from multiple sources over the last
  few
 weeks.
   Given how important push notifications are for mobile
 projects, a
core
  push
   notification plugin would be a great addition and another
  argument
for
  why
   you should use cordova.
  
   On Thu, Oct 16, 2014 at 11:58 AM, Brian LeRoux b...@brian.io
  wrote:
  
just was discussing w/ Shaz and Jesse…thoughts?
   
  
 

   
  
 

[OT] keybase invites

[Brian LeRoux]

pinging the list b/c I know we have some crypto nerds here. =)

reply to me separately off list if you'd like an invite to keybase.io (its
pretty sweet!)

Re: Review: Cordova-CLI 4.0.0 Release blog post

[Brian LeRoux]

looks great: thank you steve!

On Tue, Oct 14, 2014 at 11:24 AM, Steven Gill stevengil...@gmail.com
wrote:

 Please review and send pull requests!


 https://github.com/cordova/apache-blog-posts/blob/master/2014-10-13-cordova-4.md

Re: Independent platform release summary

[Brian LeRoux]

I am against it. Its not going to achieve the goal of alleviating
confusion. People see the CLI as the version not the platforms. I'd rather
we went to 5 if anything.
On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) 
panar...@microsoft.com wrote:

 I meant tag and start the vote for the next release :)

 On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote:

 +1
 
 -Chuck
 
 -Original Message-
 From: Jesse [mailto:purplecabb...@gmail.com]
 Sent: Thursday, October 9, 2014 2:55 PM
 To: dev@cordova.apache.org
 Subject: Re: Independent platform release summary
 
 +1 to not voting ;) , it implies we will wait 72 hours before moving on.
 
 How about if anyone is completely against 10.0.0 they voice it here, in
 the next couple hours, otherwise we move forward.
 
 @purplecabbage
 risingj.com
 
 On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com
 wrote:
 
  I don't think a vote is necessary. I'd hate to see us resort to voting
  to solve problems. Voting should be a last resort if consensus is
  split. I don't see that in this scenario.
 
  I propose we bumb the version up to 10.0.0.
 
  On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) 
  panar...@microsoft.com wrote:
 
   Lets start with a vote for 10.0.0 ? And if someone feels strongly
   about calling it something the vote could be cancelled !!
  
   On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote:
  
   Yeah agreed - Vladimir squashed the bug and what was at once point
   to be called 3.7.0 has been mainly waiting on a version number.
   Personally I am fine with 10.0.0 or 5.0.0 - Either send the message
   that platform versions are divorced from the CLI from a versioning
   perspective (though behavior is still predictable).  Leo - I think
   at least out of the gate devs will likely focus on the CLI version
   as primary.  Basically today, the cadence version of the CLI is
   what people talk about.  Heck, Cordova
   3.4.1 was 3.4.0 for all platforms but iOS.  The main message is
   that
  when
   you platform add android, you may see an npm pull for
   cordova-android@4.3.2 and that is expected.  It's just formalizing
   the message and allows independent platform rev'ing.
   
   -Chuck
   
   -Original Message-
   From: Steven Gill [mailto:stevengil...@gmail.com]
   Sent: Thursday, October 9, 2014 2:13 PM
   To: dev@cordova.apache.org
   Cc: Michal Mocny; Marcel Kinard
   Subject: Re: Independent platform release summary
   
   I think vladimir fixed the bug. We just need to release now.
   
   Only thing holding back the release now is consensus on the version
   of the cli. It seemed like most people were leaning toward 10.0.0.
   Should I move forward with that? I would just have to branch + pin
   deps
   
   Leo the documentation version dropdown box would be tied to cli
 version.
   It still makes sense to copy over platform documentation into
   platform repos and maybe copy it into docs during generation time.
   
   As for plugin pinning, plugins have more to do with platforms. I
  wouldn't
   say they aren't tied to the cli at all. I understand your point
 though.
   So far, we haven't had any plugins that won't work with previous
  versions
   (As far as I know). We should really fix the engine stuff for
   plugins so we can keep track of what platforms they work for. I'd
   like us to give warnings to users to update their plugins if newer
 versions are out.
   Cordova info should also dump what versions of plugins you have
  installed
   if it doesn't already. In combination with cordova --save  cordova
   --restore, we should be able to recommend a workflow that is easily
   reproducible on any machine.
   
   On Thu, Oct 9, 2014 at 1:44 PM, Chuck Lantz cla...@microsoft.com
  wrote:
   
Okay - so - there's a pretty nasty CLI blocker bug right now.
Plugins with dependencies don't install (this affects all
platforms).  In my opinion, we need to get a CLI release out
really soon.  Are we closed on this topic, or do we need to look
at doing the old process to get this out the door while we are
 still talking?
   
There are also a series of other bugs in the currently tagged
 3.6.4
platforms for Android, Windows, and Windows Phone 8.  These can
be handled independently, but the CLI bug can't.
   
https://issues.apache.org/jira/browse/CB-7670
   
-Chuck
   
-Original Message-
From: Treggiari, Leo [mailto:leo.treggi...@intel.com]
Sent: Thursday, October 9, 2014 12:23 PM
To: Michal Mocny
Cc: Marcel Kinard; dev
Subject: RE: Independent platform release summary
   
I'll have to admit that this seems a bit weird.  That is,
independent versions of the CLI and platforms, with a Cordova
release named something - e.g. a date?
   
Imagine a user wants to know whether the new whitelist entry in
config.xml is supported in the versions of CLI and platforms that
they have - assuming 

Re: Independent platform release summary

[Brian LeRoux]

As is 4.

This is more of an outreach, marketing, blogging, tweeting, etc problem.
Versions are for issue tracking not marketing. (Tho semver and our
respective $BIGCO's confuse that to their and our continued strife.)

(All IMO of course, happy to follow the wisdom of the crowd on this one.)
On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote:

 5 is also fine.

 On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote:

  I am against it. Its not going to achieve the goal of alleviating
  confusion. People see the CLI as the version not the platforms. I'd
 rather
  we went to 5 if anything.
  On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) 
  panar...@microsoft.com wrote:
 
   I meant tag and start the vote for the next release :)
  
   On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote:
  
   +1
   
   -Chuck
   
   -Original Message-
   From: Jesse [mailto:purplecabb...@gmail.com]
   Sent: Thursday, October 9, 2014 2:55 PM
   To: dev@cordova.apache.org
   Subject: Re: Independent platform release summary
   
   +1 to not voting ;) , it implies we will wait 72 hours before moving
 on.
   
   How about if anyone is completely against 10.0.0 they voice it here,
 in
   the next couple hours, otherwise we move forward.
   
   @purplecabbage
   risingj.com
   
   On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com
   wrote:
   
I don't think a vote is necessary. I'd hate to see us resort to
 voting
to solve problems. Voting should be a last resort if consensus is
split. I don't see that in this scenario.
   
I propose we bumb the version up to 10.0.0.
   
On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN
 TECH) 
panar...@microsoft.com wrote:
   
 Lets start with a vote for 10.0.0 ? And if someone feels strongly
 about calling it something the vote could be cancelled !!

 On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote:

 Yeah agreed - Vladimir squashed the bug and what was at once
 point
 to be called 3.7.0 has been mainly waiting on a version number.
 Personally I am fine with 10.0.0 or 5.0.0 - Either send the
 message
 that platform versions are divorced from the CLI from a
 versioning
 perspective (though behavior is still predictable).  Leo - I
 think
 at least out of the gate devs will likely focus on the CLI
 version
 as primary.  Basically today, the cadence version of the CLI is
 what people talk about.  Heck, Cordova
 3.4.1 was 3.4.0 for all platforms but iOS.  The main message is
 that
when
 you platform add android, you may see an npm pull for
 cordova-android@4.3.2 and that is expected.  It's just
 formalizing
 the message and allows independent platform rev'ing.
 
 -Chuck
 
 -Original Message-
 From: Steven Gill [mailto:stevengil...@gmail.com]
 Sent: Thursday, October 9, 2014 2:13 PM
 To: dev@cordova.apache.org
 Cc: Michal Mocny; Marcel Kinard
 Subject: Re: Independent platform release summary
 
 I think vladimir fixed the bug. We just need to release now.
 
 Only thing holding back the release now is consensus on the
 version
 of the cli. It seemed like most people were leaning toward
 10.0.0.
 Should I move forward with that? I would just have to branch +
 pin
 deps
 
 Leo the documentation version dropdown box would be tied to cli
   version.
 It still makes sense to copy over platform documentation into
 platform repos and maybe copy it into docs during generation
 time.
 
 As for plugin pinning, plugins have more to do with platforms. I
wouldn't
 say they aren't tied to the cli at all. I understand your point
   though.
 So far, we haven't had any plugins that won't work with previous
versions
 (As far as I know). We should really fix the engine stuff for
 plugins so we can keep track of what platforms they work for. I'd
 like us to give warnings to users to update their plugins if
 newer
   versions are out.
 Cordova info should also dump what versions of plugins you have
installed
 if it doesn't already. In combination with cordova --save 
 cordova
 --restore, we should be able to recommend a workflow that is
 easily
 reproducible on any machine.
 
 On Thu, Oct 9, 2014 at 1:44 PM, Chuck Lantz 
 cla...@microsoft.com
wrote:
 
  Okay - so - there's a pretty nasty CLI blocker bug right now.
  Plugins with dependencies don't install (this affects all
  platforms).  In my opinion, we need to get a CLI release out
  really soon.  Are we closed on this topic, or do we need to
 look
  at doing the old process to get this out the door while we are
   still talking?
 
  There are also a series of other bugs in the currently tagged
   3.6.4
  platforms for Android, Windows, and Windows Phone 8.  These can
  be handled

Re: Independent platform release summary

[Brian LeRoux]

OR we move to named releases externally.

Cordova MX === 4.0
On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote:

 4 was also discussed as fine, and in isolation would have been our choice
 for sure -- but we worried that with the impending cordova-4.0 releases,
 it would confuse users and not mark a clear departure from cadver.

 The more I think about it though, the less important I think that worry
 is.  Maybe 4.0 is fine.

 (Apologies to Steve, who just wants to get this over with)

 On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote:

  As is 4.
 
  This is more of an outreach, marketing, blogging, tweeting, etc problem.
  Versions are for issue tracking not marketing. (Tho semver and our
  respective $BIGCO's confuse that to their and our continued strife.)
 
  (All IMO of course, happy to follow the wisdom of the crowd on this one.)
  On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote:
 
   5 is also fine.
  
   On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote:
  
I am against it. Its not going to achieve the goal of alleviating
confusion. People see the CLI as the version not the platforms. I'd
   rather
we went to 5 if anything.
On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) 
panar...@microsoft.com wrote:
   
 I meant tag and start the vote for the next release :)

 On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote:

 +1
 
 -Chuck
 
 -Original Message-
 From: Jesse [mailto:purplecabb...@gmail.com]
 Sent: Thursday, October 9, 2014 2:55 PM
 To: dev@cordova.apache.org
 Subject: Re: Independent platform release summary
 
 +1 to not voting ;) , it implies we will wait 72 hours before
 moving
   on.
 
 How about if anyone is completely against 10.0.0 they voice it
 here,
   in
 the next couple hours, otherwise we move forward.
 
 @purplecabbage
 risingj.com
 
 On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill 
 stevengil...@gmail.com
  
 wrote:
 
  I don't think a vote is necessary. I'd hate to see us resort to
   voting
  to solve problems. Voting should be a last resort if consensus
 is
  split. I don't see that in this scenario.
 
  I propose we bumb the version up to 10.0.0.
 
  On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN
   TECH) 
  panar...@microsoft.com wrote:
 
   Lets start with a vote for 10.0.0 ? And if someone feels
  strongly
   about calling it something the vote could be cancelled !!
  
   On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com
  wrote:
  
   Yeah agreed - Vladimir squashed the bug and what was at once
   point
   to be called 3.7.0 has been mainly waiting on a version
 number.
   Personally I am fine with 10.0.0 or 5.0.0 - Either send the
   message
   that platform versions are divorced from the CLI from a
   versioning
   perspective (though behavior is still predictable).  Leo - I
   think
   at least out of the gate devs will likely focus on the CLI
   version
   as primary.  Basically today, the cadence version of the CLI
 is
   what people talk about.  Heck, Cordova
   3.4.1 was 3.4.0 for all platforms but iOS.  The main message
 is
   that
  when
   you platform add android, you may see an npm pull for
   cordova-android@4.3.2 and that is expected.  It's just
   formalizing
   the message and allows independent platform rev'ing.
   
   -Chuck
   
   -Original Message-
   From: Steven Gill [mailto:stevengil...@gmail.com]
   Sent: Thursday, October 9, 2014 2:13 PM
   To: dev@cordova.apache.org
   Cc: Michal Mocny; Marcel Kinard
   Subject: Re: Independent platform release summary
   
   I think vladimir fixed the bug. We just need to release now.
   
   Only thing holding back the release now is consensus on the
   version
   of the cli. It seemed like most people were leaning toward
   10.0.0.
   Should I move forward with that? I would just have to branch
 +
   pin
   deps
   
   Leo the documentation version dropdown box would be tied to
 cli
 version.
   It still makes sense to copy over platform documentation into
   platform repos and maybe copy it into docs during generation
   time.
   
   As for plugin pinning, plugins have more to do with
 platforms.
  I
  wouldn't
   say they aren't tied to the cli at all. I understand your
 point
 though.
   So far, we haven't had any plugins that won't work with
  previous
  versions
   (As far as I know). We should really fix the engine stuff for
   plugins so we can keep track of what platforms they work for.
  I'd
   like us to give warnings to users to update their plugins if
   newer
 versions are out.
   Cordova info should also dump what

Re: [iOS 8] Status of WKWebView work

[Brian LeRoux]

I have some questions! What happens when you background / does it keep
running? Since you're running localhost, how do you deal with 1 app
(random port collision possible?)

On Wed, Oct 8, 2014 at 10:33 AM, Shazron shaz...@gmail.com wrote:

 Not sure if it's only bound to local requests from localhost. Since it's
 for experimental reasons, I'm not too concerned for security. I'm still
 opting for the WKWebView loadFileURL way as the option we use for our
 users, once that is out.

 On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage purplecabb...@gmail.com
 wrote:

  What about other requests from the network? Is the server accessible to
  network peers?
 
  Sent from my iPhone
 
   On Oct 8, 2014, at 10:26 AM, Shazron shaz...@gmail.com wrote:
  
   I'll release the local webserver soon as a plugin, it was just a proof
 of
   concept. It should work with existing Cordova versions as well, but
 will
   not have a way to secure access to the local web server from other
   (background) running apps.
  
   On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve agri...@chromium.org
  wrote:
  
   On Fri, Sep 5, 2014 at 2:40 PM, Shazron shaz...@gmail.com wrote:
  
   I figure I will write this all up before the official release of iOS
 8
   next
   week (probability high) and everyone asking about support.
  
   It has stalled because the WKWebView cannot load files using the
  file://
   protocol since iOS 8 beta 4.
  
   This bug has been filed with Apple weeks ago:
   http://www.openradar.me/radar?id=5839348817723392
  
   I even checked WebKit check-ins if there was any progress, so far,
 no:
  
 
 http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/API/Cocoa?order=datedesc=1
   (but it's entirely possible the loading code is in another part of
 the
   tree).
  
   The alternative is to run a local web server, which works great.
  However,
   this will open up a can of worms possibly with Apple, I'm not sure.
  
   Shaz, did you implement a prototype with a local web server? Would be
   useful to see how the code for this works.
  
  
  
  
   The other interesting tidbit is, with WKWebView, for locally loaded
  files
   using the file:// protocol, cross-domain restrictions now apply,
 unlike
   UIWebView's behaviour. To have the same behaviour as UIWebView, we
  would
   need to proxy these requests (modify xhr.open to go to our proxy,
 which
   requires the local web server).
  
   The bridge works great, and plugins work great.
  
 

Re: [iOS 8] Status of WKWebView work

[Brian LeRoux]

I guess if it isn't running in the background then a collision is
effectively impossible anyhow.

On Wed, Oct 8, 2014 at 11:53 AM, Shazron shaz...@gmail.com wrote:

 But for 2, there is a chance of port collision still of course, nothing we
 can do about that. The ideal way is to get a random port, but this requires
 more Cordova integration which I am trying to avoid (since we need to
 specify the URL in the content tag, we need to know the port as well)

 On Wed, Oct 8, 2014 at 11:51 AM, Shazron shaz...@gmail.com wrote:

 1. Does it run in the background? No. Unless we put up some variables in
 Info.plist, which are reserved for certain types of apps (navigation apps,
 etc)
 2. Local web server port collision? This will be specified in the plugin
 in a preference.

 On Wed, Oct 8, 2014 at 11:46 AM, Brian LeRoux b...@brian.io wrote:

 I have some questions! What happens when you background / does it keep
 running? Since you're running localhost, how do you deal with 1 app
 (random port collision possible?)

 On Wed, Oct 8, 2014 at 10:33 AM, Shazron shaz...@gmail.com wrote:

 Not sure if it's only bound to local requests from localhost. Since it's
 for experimental reasons, I'm not too concerned for security. I'm still
 opting for the WKWebView loadFileURL way as the option we use for our
 users, once that is out.

 On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage purplecabb...@gmail.com
 
 wrote:

  What about other requests from the network? Is the server accessible
 to
  network peers?
 
  Sent from my iPhone
 
   On Oct 8, 2014, at 10:26 AM, Shazron shaz...@gmail.com wrote:
  
   I'll release the local webserver soon as a plugin, it was just a
 proof of
   concept. It should work with existing Cordova versions as well, but
 will
   not have a way to secure access to the local web server from other
   (background) running apps.
  
   On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve 
 agri...@chromium.org
  wrote:
  
   On Fri, Sep 5, 2014 at 2:40 PM, Shazron shaz...@gmail.com
 wrote:
  
   I figure I will write this all up before the official release of
 iOS 8
   next
   week (probability high) and everyone asking about support.
  
   It has stalled because the WKWebView cannot load files using the
  file://
   protocol since iOS 8 beta 4.
  
   This bug has been filed with Apple weeks ago:
   http://www.openradar.me/radar?id=5839348817723392
  
   I even checked WebKit check-ins if there was any progress, so
 far, no:
  
 
 http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/API/Cocoa?order=datedesc=1
   (but it's entirely possible the loading code is in another part
 of the
   tree).
  
   The alternative is to run a local web server, which works great.
  However,
   this will open up a can of worms possibly with Apple, I'm not
 sure.
  
   Shaz, did you implement a prototype with a local web server? Would
 be
   useful to see how the code for this works.
  
  
  
  
   The other interesting tidbit is, with WKWebView, for locally
 loaded
  files
   using the file:// protocol, cross-domain restrictions now apply,
 unlike
   UIWebView's behaviour. To have the same behaviour as UIWebView, we
  would
   need to proxy these requests (modify xhr.open to go to our proxy,
 which
   requires the local web server).
  
   The bridge works great, and plugins work great.
  
 

Re: [iOS 8] Status of WKWebView work

[Brian LeRoux]

Will def be a fun alpha…fwiw I think this is The Future™ for the
architecture. Opens lots of doors for interop and reuse. Between apps.
Between devices. Also clears up the network security policy whitelist gong
show.

On Wed, Oct 8, 2014 at 12:31 PM, Joe Bowser bows...@gmail.com wrote:

 How can you guarantee that the port will be released when it goes in the
 background and not still be bound? That sounds like a main point of
 failure.  Would you have it increment to the next port if the port is
 bound?

 On Wed, Oct 8, 2014 at 12:27 PM, Brian LeRoux b...@brian.io wrote:

 I guess if it isn't running in the background then a collision is
 effectively impossible anyhow.

 On Wed, Oct 8, 2014 at 11:53 AM, Shazron shaz...@gmail.com wrote:

  But for 2, there is a chance of port collision still of course, nothing
 we
  can do about that. The ideal way is to get a random port, but this
 requires
  more Cordova integration which I am trying to avoid (since we need to
  specify the URL in the content tag, we need to know the port as well)
 
  On Wed, Oct 8, 2014 at 11:51 AM, Shazron shaz...@gmail.com wrote:
 
  1. Does it run in the background? No. Unless we put up some variables
 in
  Info.plist, which are reserved for certain types of apps (navigation
 apps,
  etc)
  2. Local web server port collision? This will be specified in the
 plugin
  in a preference.
 
  On Wed, Oct 8, 2014 at 11:46 AM, Brian LeRoux b...@brian.io wrote:
 
  I have some questions! What happens when you background / does it keep
  running? Since you're running localhost, how do you deal with 1 app
  (random port collision possible?)
 
  On Wed, Oct 8, 2014 at 10:33 AM, Shazron shaz...@gmail.com wrote:
 
  Not sure if it's only bound to local requests from localhost. Since
 it's
  for experimental reasons, I'm not too concerned for security. I'm
 still
  opting for the WKWebView loadFileURL way as the option we use for our
  users, once that is out.
 
  On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage 
 purplecabb...@gmail.com
  
  wrote:
 
   What about other requests from the network? Is the server
 accessible
  to
   network peers?
  
   Sent from my iPhone
  
On Oct 8, 2014, at 10:26 AM, Shazron shaz...@gmail.com wrote:
   
I'll release the local webserver soon as a plugin, it was just a
  proof of
concept. It should work with existing Cordova versions as well,
 but
  will
not have a way to secure access to the local web server from
 other
(background) running apps.
   
On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve 
  agri...@chromium.org
   wrote:
   
On Fri, Sep 5, 2014 at 2:40 PM, Shazron shaz...@gmail.com
  wrote:
   
I figure I will write this all up before the official release
 of
  iOS 8
next
week (probability high) and everyone asking about support.
   
It has stalled because the WKWebView cannot load files using
 the
   file://
protocol since iOS 8 beta 4.
   
This bug has been filed with Apple weeks ago:
http://www.openradar.me/radar?id=5839348817723392
   
I even checked WebKit check-ins if there was any progress, so
  far, no:
   
  
 
 http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/API/Cocoa?order=datedesc=1
(but it's entirely possible the loading code is in another part
  of the
tree).
   
The alternative is to run a local web server, which works
 great.
   However,
this will open up a can of worms possibly with Apple, I'm not
  sure.
   
Shaz, did you implement a prototype with a local web server?
 Would
  be
useful to see how the code for this works.
   
   
   
   
The other interesting tidbit is, with WKWebView, for locally
  loaded
   files
using the file:// protocol, cross-domain restrictions now
 apply,
  unlike
UIWebView's behaviour. To have the same behaviour as
 UIWebView, we
   would
need to proxy these requests (modify xhr.open to go to our
 proxy,
  which
requires the local web server).
   
The bridge works great, and plugins work great.
   
  
 
 
 
 
 

Re: Independent platform release summary

[Brian LeRoux]

This doc is a really great summary: thank you Michal (and everyone else for
the input). Super agree with starting from positive goals Marcel.

I've been asking around other Apache projects (Jackrabbit and Sling) and
the Gentoo Linux guys. This problem is hard. The good news is: we're not
the only ones that have run into it. The general consensus I'm getting back
is to pin the versions sort of like we used to do. So the CLI is version 4
and then so are the platforms. This means artificial tagging of the repos
in scenarios where one is ready to ship and others are not. It also means
keeping MASTER green and deploy-able at all times by working from feature
branches so that a release tag is a trivial annoyance instead of a full
regression testing cycle. Versions are quite specifically for issue
tracking so keeping that as simple as possible means higher quality bug
reporting and (hopefully) resolution.

Anyhow: look fwd to the conversation. Feels like we're making some progress.


On Tue, Oct 7, 2014 at 12:01 PM, Marcel Kinard cmarc...@gmail.com wrote:

 On Oct 7, 2014, at 2:13 PM, Michal Mocny mmo...@chromium.org wrote:

  Do not confuse developers goal hopefully covers your points about
 communication and information

 It partially covers it.

 To be more explicit, I'm trying to turn a negative goal into a positive
 goal. So instead of how do we not mess this up I'm going for what are we
 really trying to achieve.

 And I'm also trying to twist a cordova-dev goal into a cordova-user goal.
 I don't think we know what the ideal user experience is, so it is hard to
 talk about how to achieve that.

RE: Independent platform release summary

[Brian LeRoux]

Maybe pinning platforms and the CLI wasn't so bad after all.
On Oct 3, 2014 2:34 PM, Treggiari, Leo leo.treggi...@intel.com wrote:

 I agree that this is, and will be, confusing.  It was confusing today in
 our own discussions in our own team (who are, in general, fairly Cordova
 savvy) to be talking about the Android store issue related to Cordova
 3.5.1.  E.g. what did it mean to be talking about Cordova 3.5.1, and
 what would a user need to do to get the fix?  What I took away was that a
 user would need  Cordova CLI 3.5.0-0.2.7.  However, I wouldn't be surprised
 if you told me that was wrong...

 Anyway, a completely different (and possibly immediately dismissible)
 idea.  What if a Cordova CLI version number was the same as the highest
 version number of the platforms supported by that Cordova CLI version.
 E.g. if the latest highest platform version was Android 3.5.1, then the
 Cordova CLI version would be 3.5.1.  The supported other-platform version
 might be lower - e.g. Windows 3.4.2 (totally made up version number...).

 That doesn't instantly solve all problems.  What if the next platform
 release after Android 3.5.1 was Windows 3.4.3?  Cordova CLI can't remain at
 the highest version number.  So would Cordova CLI become 3.5.2 or 3.5.1-1?
 Should the Windows release be 3.5.2? Are there a specific set of features
 associated with a specific platform major version number?  It seems that a
 platform release named 3.x.y is expected to have a certain set of features
 implemented.  Is a platform release named 3.4.x expected to have a certain
 set of features and a platform named 3.5.x expected to have those features
 plus some additional feature?

 In general, what can a user expect these version numbers to mean.  E.g. if
 I as an app developer want to use a particular recently added feature on
 multiple platforms, how do I determine which versions of which platforms
 support the feature and which Cordova CLI version gives me what I want?

 Sorry, but it is confusing...

 Leo

 -Original Message-
 From: Marcel Kinard [mailto:cmarc...@gmail.com]
 Sent: Friday, October 03, 2014 1:56 PM
 To: dev@cordova.apache.org
 Subject: Re: Independent platform release summary

 If a bump to major indicates an API change, how is that visible to users?
 Do users look at the CLI version as the version of Cordova, or are we
 expecting users to look at the version of every Cordova component to
 understand where majors got bumped? While I agree the latter is more
 correct technically, I think users have been and are currently assuming the
 former. It would take some education to switch that.

 On Oct 2, 2014, at 7:51 PM, Andrew Grieve agri...@chromium.org wrote:

  I don't think it's necessary to bump CLI major when platforms bump major.
  Platforms and CLI are linked only superficially anyways.


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Independent platform release summary

[Brian LeRoux]

I'm down with jumping to 4.x but not convinced a jump to 5.x would actually
spur more understanding. (Also thanks for tackling this Steve.)

On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill stevengil...@gmail.com wrote:

 I'm not opposed to a big version jump. It would draw attention to the fact
 that we are changing our versioning  releasing process. How do others
 feel?

 -Steve

 On Thu, Oct 2, 2014 at 11:45 AM, Shazron shaz...@gmail.com wrote:

  Thanks Steve for writing that up.
  I can definitely see the confusion in messaging, especially at the start
  of this new process.
 
  So for 2) CLI + Lib version I am proposing a radical idea (à la Windows
  10) where we jump to a new version totally separate from the current 3.x
  series to further detach the association of the CLI version with platform
  versions. Version 5.x? Not sure how sem-ver kosher it is.
 
  I already have one scenario. I sent out pull requests for docs and the
 CLI
  for the new iPhone 6 icons and splash screens. These will be in the next
  iOS platform release 3.7.0, and if another platform didn't take 3.8.0
  already, most likely CLI 3.8.0.
 
  This would mean the docs would be at 3.8.0, CLI at 3.8.0 but cordova-ios
  will be at 3.7.0. This is how the messaging will look like if I were to
  write a blog post:
  To get cordova-cli support for iPhone 6 splash screens and icons, please
  update to cordova-cli 3.8.0, which will grab the 3.7.0 version of
  cordova-ios where this feature is implemented. Check out the 3.8.0
  cordova-docs for usage. A bit clunky.
 
 
 
 
 
  On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill stevengil...@gmail.com
  wrote:
 
  Hey All,
 
  I wanted to give summary of where I believe this process is going and
  answer any questions you all might have. None of this is set in stone,
 so
  please provide feedback so we can iron this out.
 
  1) Platforms can now release independently
 
  If iOS wants to release 3.7.0, it doesn't have to wait for other
 platforms
  to be ready to release. Just run through
 
 
 https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
  and do a tools release.
 
  2) CLI + Lib version will rise very quickly.
 
  Right now, CLI is about to be released at version 3.7.0. No platforms
 are
  currently at version 3.7.0. Say iOS wants to release 3.7.0 next week,
 they
  could do that, update the CLI to version 3.8.0. I suggest a platform
 being
  released would cause the CLI to do a minor release (MAJOR.MINOR.PATCH -
  3.8.0). But this is obviously open to discussion.
 
  3) Docs
 
  Docs version will now be tied to CLI. If we do a major or minor release
 of
  the CLI, docs should be regenerated to match the version of the CLI. Say
  iOS 3.7.0 requires the newest version of the CLI, we can make note of
 that
  in docs + blog post. Maybe we list the platform versions associated to
 CLI
  somewhere in the docs?
 
  4) Helping users debug
 
  Cordova.version  cordova.platformVersion will both return the version
 of
  the platform, not the cli. Users can easily tell you what version of
  cordova-platform they are using by doing this. Generated cordova.js
 files
  in projects will also have this information at the top of the file along
  with commit hash.
 
  5) Messaging
 
  We need to be clear about this in our messaging to users. This is a
 change
  from how we have been doing things and I foresee some confusion at the
  beginning. Moving platforms over to package.json eventually will help
  users
  see that platforms are independent, but we need to do more now to help
  users adapt to this change.
 
  They need to know to expect the CLI version to jump quickly, and to know
  that platform versions != cordova-cli version.
 
  Blog posts can list platforms cli was tested with, similarly to how we
  list
  what plugin versions the cli was tested with when releasing. (see the
  bottom of
  http://cordova.apache.org/announcements/2014/09/22/cordova-361.html for
  an
  example)
 
  Hopefully I didn't leave out anything major. Feedback please!
 
 
 

Re: [DISCUSS] shrinkwrap

[Brian LeRoux]

it is, and as the podcast said, shrinkwrap isn't quite ready for prime time
anyhow. I'll be keeping an eye on it (as will others) so we can be sure to
take advantage of it when it becomes stable and reasonable to use.

On Wed, Oct 1, 2014 at 3:12 PM, Steven Gill stevengil...@gmail.com wrote:

 In the past, semver has caused me problems due to having modules npm
 linked. Ex Running npm shrinkwrap on cordova-lib while i have cordva-js
 linked will break.

 Shrinkwrap also requires those dependencies to already be on npm. So if I
 reference cordova-js 3.7.0 and it hasn't been published yet, it will fail.

 Overall, I find it to be very annoying. I can follow the instructions step
 by step while releasing to get around some of these problems (publishing
 dependent packages first, remembering to unlink) but it just feels like a
 waste of time to me.

 Another problem is if we leave it in master, it will cause headaches as we
 do local dev. Will have to remember to remove it.

 Pinning seems like much better option IMO

 On Wed, Oct 1, 2014 at 1:46 PM, Marcel Kinard cmarc...@gmail.com wrote:

  From my scars of the last release, what I'd suggest as closer to the
 ideal
  of benefits of shrinkwrap with a lower cost would be to publish to a
  private npm repo and use something like the --registry flag to test.
 Using
  a private registry would also give us the opportunity to wipe any
 published
  packages in case a republish is needed, to avoid bumping the version
  numbers.  https://issues.apache.org/jira/browse/CB-7550
 
  Until we have a private registry for release testing, I agree with Steve
  that rc's should not be published to npm, and instead use --usegit.
 
  On Oct 1, 2014, at 4:25 PM, Andrew Grieve agri...@chromium.org wrote:
 
   The root of what I meant I guess, was that if shrinkwrap doesn't work
   without publishing, then let's just publish and don't sweat version
  numbers
   jumping by more than one. If we can get shrinkwrap to work through
  another
   means (private npm repo?), than that's even better.
  
   On Wed, Oct 1, 2014 at 4:00 PM, Josh Soref jso...@blackberry.com
  wrote:
  
   Steven Gill wrote:
   we can test platform rc's with --usegit and
   eventually a private npm registry for testing.
  
   +1
  
  
 
 

Re: WKWebView for iOS8

[Brian LeRoux]

Web server sounding better all the time.

On Thursday, September 25, 2014, Joe Bowser bows...@gmail.com wrote:

 I wanted to unpack the android_assets to the app storage to fix various
 problems with the file URI but it was vetoed every time.  This sounds very
 similar.
 On Sep 25, 2014 10:39 PM, Jesse purplecabb...@gmail.com javascript:;
 wrote:

  FYI, Windows Phone 7 had to unpack all www/ files to temp (
 IsolatedStorage
  in wp7 world )
  This was because of the way that the app packaged assets, they were just
  resources inside the .dll, so index.html could load, but could not
  reference any other relative files.
  Also because the .dll resource list was not query-able, I had to
 generate a
  list of all files in the www/ folder at build time, so I knew what to
  unpack.
 
  I originally wanted to just unpack files on the first time the app was
  loaded, but quickly realized that unpacking was quick enough that the
 extra
  complexity of tracking what was modified was not worth it, so every
 launch
  of the app was a fresh unpack of the files.
 
  Just a little history for y'all, but I do recommend you measure the
 impact
  of the simple solution before you decide it's not good enough.
 
  @purplecabbage
  risingj.com
 
  On Thu, Sep 25, 2014 at 9:13 PM, Ally Ogilvie aogil...@wizcorp.jp
 javascript:; wrote:
 
   Not able to load web resource from within html that reference
   Library/Caches/*.jpg :(
   As you said; looks like a total whitelist-style security policy.
  
   On Fri, Sep 26, 2014 at 12:44 PM, Ally Ogilvie aogil...@wizcorp.jp
 javascript:;
   wrote:
  
Not too bothered about that as long as all our assets (images/sounds)
  can
be downloaded into cache and the html in /tmp can load them.
   
As discussed a previous thread I (we/Wizcorp) have a native loader to
steam the game/app from cloudz. As long as we can put html to /tmp
 and
assets to cache, html is light enough to be re-downloaded each time.
   
For offline mode we may restore html to /tmp from a saved blob in
   database
in /cache or NSData in NSUserDefaults.
   
   
   
On Fri, Sep 26, 2014 at 12:13 PM, Shazron shaz...@gmail.com
 javascript:; wrote:
   
Also, since it is in tmp -- eventually you will leave to copy over
 the
www,
*again* once the system clears it out. That's no good.
   
On Thu, Sep 25, 2014 at 7:50 PM, Shazron shaz...@gmail.com
 javascript:; wrote:
   
 Ally - I seriously doubt it, this appears to be more low level.
 When
using
 loadHTMLString to load the initial HTML file it is fine, but any
   assets
 that the HTML tries to load is subject to the low level loader
  which I
 presume has a security policy disallowing unauthorized locations.

 You could modify my test project to test it out but it has to be
 dynamically generated since the (hard-coded) paths will be
 different
   on
 each environment.

 In any case if it worked, it would not be a 'simple' solution.

 --- An idea, perhaps on first load, it loads on UIWebView, then
 next
time,
 WKWebView after the bundle has been copied? The more that I think
   about
it,
 none of this is a good solution, it's really a hack. I would say
  local
web
 server is looking more and more better.

 On Thu, Sep 25, 2014 at 7:25 PM, Ally Ogilvie 
 aogil...@wizcorp.jp javascript:;
wrote:

 Not tested but i'd be interested to know if once the html from
 /tmp
   is
 loaded, can the html pull in images using img / with a path of
file:///
 absolute path to library caches /myImage.jpg.

 On Fri, Sep 26, 2014 at 11:14 AM, Brian LeRoux b...@brian.io
 javascript:; wrote:

  cool, guess this is a bit of a startup penalty (but that'd be
  it?)
 
  On Thu, Sep 25, 2014 at 7:05 PM, Shazron shaz...@gmail.com
 javascript:;
   wrote:
 
   Mixed news from iOS 8.0.2. Only local files from *tmp* can be
loaded.
  Test
   using https://github.com/shazron/WKWebViewFIleUrlTest
  
  
  
   Documents, Library, Library/Caches and inside your app bundle
  --
   no
 files
   there can be loaded using the file:// protocol, only from
 tmp.
  
  
  
   The Safari file upload fix probably allowed tmp file://
 loading
thus
   allowing it for WKWebView as well.
  
  
   So we can use this -- all we need is to copy the www folder
 to
   tmp,
 easy.
  
   On Thu, Sep 18, 2014 at 9:03 AM, Shazron shaz...@gmail.com
 javascript:;
wrote:
  
Yeah no update in iOS 8 GM. So moving to contingency. I
 still
think
  it's
   a
bug and not a policy change:
https://issues.apache.org/jira/browse/CB-7539
   
Should be pretty easy (minus the securing it part is a bit
  more
 work).
   
   
On Wed, Sep 17, 2014 at 8:31 PM, Ally Ogilvie 
aogil...@wizcorp.jp javascript:;
   wrote

Re: Who is going to Chrome Dev Summit Nov19-20?

[Brian LeRoux]

I'll be there. Looking forward to it. Should plan to do a Cordova
(beer|meet)up?

On Thu, Sep 25, 2014 at 12:57 PM, Michal Mocny mmo...@chromium.org wrote:

 I haven't seen a schedule of talks.

 I would be shocked if their wasn't some talk of Polymer (not sure about
 Designer).  I'm less sure about CDE -- its been popular after I/O but isn't
 really fundamental to the direction of the web, and the conference talks
 are already pretty tight.

 Our codelab/booth is very likely to demonstrate CDE, and possibly Polymer 
 Material Design, though, since CDE supports deploy-to-mobile using the
 cordova-based CADT companion app.  This was covered in a recent chromium
 blogpost, by the way:

 http://blog.chromium.org/2014/09/now-with-faster-dev-workflow-and-modern.html

 -Michal

 On Thu, Sep 25, 2014 at 3:20 PM, Carlos Santana csantan...@gmail.com
 wrote:

  Great !!, looking forward to meet again guys
 
  What about Chrome Dev Editor or Polymer Designer with Cordova ?
 
  On Thu, Sep 25, 2014 at 2:52 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
   Some of us Googlers will be there.  Currently looking for a way to
  present
   cordova, looks like we won't have any talks but may do a codelab /
 booth.
  
   -Michal
  
   On Thu, Sep 25, 2014 at 2:40 PM, Carlos Santana csantan...@gmail.com
   wrote:
  
I was able to get a ticket [1] to attend. Now waiting on corporate
  travel
approval ...
   
It will be awesome to meet with committers, contributors, end users
 of
Cordova while there.
   
[1]: http://developer.chrome.com/devsummit
   
--
Carlos Santana
csantan...@gmail.com
   
  
 
 
 
  --
  Carlos Santana
  csantan...@gmail.com
 

Re: new NPM 2.x

[Brian LeRoux]

that was really good. my takeaway: lets use shrinkwrap once they add all
this new hotness

On Thu, Sep 25, 2014 at 12:42 PM, Carlos Santana csantan...@gmail.com
wrote:

 Some of you might find this podcast [1] interesting, straight from the
 horse's mouth

 They discuss npm 2.x, opinions about semver, and modules using pre-release
 strings as production packages, shrinkwrap, etc..

 [1]:

 http://javascriptjabber.com/127-jsj-changes-in-npm-land-with-forrest-norvell-rebecca-turner-ben-coe-and-isaac-z-schlueter


 On Mon, Sep 22, 2014 at 1:46 PM, Michal Mocny mmo...@chromium.org wrote:

  1. pretty cool to be mentioned!
  2. The post led me to find:
  https://gist.github.com/othiym23/4ac31155da23962afd0e  which is
 basically
  a
  monkey patch for the recently-discussed-on-list npm upgrade command.
 
  -Michal
 
  On Mon, Sep 22, 2014 at 12:46 PM, purplecabbage purplecabb...@gmail.com
 
  wrote:
 
   And a good read for Cordova contributors, as it discusses
   dependency/versioning issues, which bites us frequently too.
  
   Sent from my iPhone
  
On Sep 22, 2014, at 9:37 AM, Ray Camden rayca...@adobe.com wrote:
   
Gotcha. So not an issue for end users of Cordova - but perhaps for
  plugin
authors.
   
   
On 9/22/14, 11:34 AM, Ian Clelland iclell...@chromium.org
 wrote:
   
It shouldn't matter for users, but I have seen several issues in the
   past
where using the wrong version of npm means that you can't publish
   modules
or plugins. It's something to be aware of, at least.
   
On Mon, Sep 22, 2014 at 12:30 PM, Ray Camden rayca...@adobe.com
   wrote:
   
Being lazy, but can you explain why it matters? Ie, is there a
 reason
*not* to just upgrade? I assume most folks would think, ³new
 version
  of
npm, just update and don¹t worry about it² - but does it impact
 using
Cordova?
   
   
On 9/22/14, 11:09 AM, Carlos Santana csantan...@gmail.com
  wrote:
   
NPM 2.x was released last week.
   
  
 



 --
 Carlos Santana
 csantan...@gmail.com

Re: new NPM 2.x

[Brian LeRoux]

ya that whole 0.x.y debacle remains inconclusive. seems like the world
actually starts at 1.0 …starting now. (idk, its impossible to enforce
semver so its always going to be a nice idea…unless we get a lang contracts
like eiffel I guess)

talked to laurie about the scoped packages and those are eventually coming
to the public reg so we should be able to use them eventually (yay!)

On Thu, Sep 25, 2014 at 6:17 PM, Michal Mocny mmo...@chromium.org wrote:

 Yes, that was great.

 Also: 0.x.y is possibly a bad idea?  (actually that seemed inconclusive,
 seems npm will continue to not treat 0. versions as special, but maybe one
 day that will change?)

 Also: scoped packages seem to be enterprise only (a scope roughly
 corresponds to a registry, it seems), but they also mentioned other
 grouping concepts.  Would be interesting to replace cordova-FOO with
 @cordova/FOO, especially if we could actually vet which packages go into
 that namespace..

 -Michal

 On Thu, Sep 25, 2014 at 7:29 PM, Brian LeRoux b...@brian.io wrote:

  that was really good. my takeaway: lets use shrinkwrap once they add all
  this new hotness
 
  On Thu, Sep 25, 2014 at 12:42 PM, Carlos Santana csantan...@gmail.com
  wrote:
 
   Some of you might find this podcast [1] interesting, straight from the
   horse's mouth
  
   They discuss npm 2.x, opinions about semver, and modules using
  pre-release
   strings as production packages, shrinkwrap, etc..
  
   [1]:
  
  
 
 http://javascriptjabber.com/127-jsj-changes-in-npm-land-with-forrest-norvell-rebecca-turner-ben-coe-and-isaac-z-schlueter
  
  
   On Mon, Sep 22, 2014 at 1:46 PM, Michal Mocny mmo...@chromium.org
  wrote:
  
1. pretty cool to be mentioned!
2. The post led me to find:
https://gist.github.com/othiym23/4ac31155da23962afd0e  which is
   basically
a
monkey patch for the recently-discussed-on-list npm upgrade command.
   
-Michal
   
On Mon, Sep 22, 2014 at 12:46 PM, purplecabbage 
  purplecabb...@gmail.com
   
wrote:
   
 And a good read for Cordova contributors, as it discusses
 dependency/versioning issues, which bites us frequently too.

 Sent from my iPhone

  On Sep 22, 2014, at 9:37 AM, Ray Camden rayca...@adobe.com
  wrote:
 
  Gotcha. So not an issue for end users of Cordova - but perhaps
 for
plugin
  authors.
 
 
  On 9/22/14, 11:34 AM, Ian Clelland iclell...@chromium.org
   wrote:
 
  It shouldn't matter for users, but I have seen several issues in
  the
 past
  where using the wrong version of npm means that you can't
 publish
 modules
  or plugins. It's something to be aware of, at least.
 
  On Mon, Sep 22, 2014 at 12:30 PM, Ray Camden 
 rayca...@adobe.com
  
 wrote:
 
  Being lazy, but can you explain why it matters? Ie, is there a
   reason
  *not* to just upgrade? I assume most folks would think, ³new
   version
of
  npm, just update and don¹t worry about it² - but does it impact
   using
  Cordova?
 
 
  On 9/22/14, 11:09 AM, Carlos Santana csantan...@gmail.com
wrote:
 
  NPM 2.x was released last week.
 

   
  
  
  
   --
   Carlos Santana
   csantan...@gmail.com
  
 

Re: WKWebView for iOS8

[Brian LeRoux]

cool, guess this is a bit of a startup penalty (but that'd be it?)

On Thu, Sep 25, 2014 at 7:05 PM, Shazron shaz...@gmail.com wrote:

 Mixed news from iOS 8.0.2. Only local files from *tmp* can be loaded. Test
 using https://github.com/shazron/WKWebViewFIleUrlTest



 Documents, Library, Library/Caches and inside your app bundle -- no files
 there can be loaded using the file:// protocol, only from tmp.



 The Safari file upload fix probably allowed tmp file:// loading thus
 allowing it for WKWebView as well.


 So we can use this -- all we need is to copy the www folder to tmp, easy.

 On Thu, Sep 18, 2014 at 9:03 AM, Shazron shaz...@gmail.com wrote:

  Yeah no update in iOS 8 GM. So moving to contingency. I still think it's
 a
  bug and not a policy change:
  https://issues.apache.org/jira/browse/CB-7539
 
  Should be pretty easy (minus the securing it part is a bit more work).
 
 
  On Wed, Sep 17, 2014 at 8:31 PM, Ally Ogilvie aogil...@wizcorp.jp
 wrote:
 
  Interested in any updates if you have 'em @Shazron ?
  Following Brian's tweet i'm kinda hoping there has been a breakthrough
 to
  load local files!
 
  Gonna switch to WKWebViews from iOS 8 in ma WizViewManager plugin.
  (WizViewManager is a WebView creator and manager for iOS and Android -
  sorta like IAB)
 
  On Thu, Aug 14, 2014 at 6:08 AM, Brian LeRoux b...@brian.io wrote:
 
   orly
  
  
   On Wed, Aug 13, 2014 at 1:57 PM, Shazron shaz...@gmail.com wrote:
  
External urls of course work. The other alternative is to host www
contents on a local webserver, and for CORs use the whitelist.
   
On Wed, Aug 13, 2014 at 1:51 PM, Shazron shaz...@gmail.com wrote:
 Well, bad news, the workaround doesn't work. Nothing from a
 file://
 url will load in a WKWebView in an iOS 8 beta 5 device.
 Assumption 1 below fails.

 Assumptions:
 1. WKWebView can load resources from tmp / Documents / Library /
Library/Caches
 2. Can copy www folder in app bundle to tmp / Documents / Library
 /
 Library/Caches

 On Wed, Aug 13, 2014 at 11:18 AM, Shazron shaz...@gmail.com
  wrote:
 Jesse had a great idea -- surely you are allowed to load from tmp
  or
 Documents. Assuming I can copy off the app bundle, I would copy
 the
 www folder into tmp or Documents, and load the index.html from
  there.
 This is the Windows Phone Cordova approach I believe.

 Assumptions:
 1. WKWebView can load resources from tmp or Documents
 2. Can copy www folder in app bundle to tmp or Documents

 On Wed, Aug 13, 2014 at 11:07 AM, Shazron shaz...@gmail.com
  wrote:
 Bad news - local file loading in a WKWebView is borked ever
 since
  iOS
8 beta 4.

 Not sure if there is some sort of new security model for loading
   local
 files in WKWebView = beta 4.WKWebView cannot load local files
 in
  its
 app bundle anymore you get a blank screen, when on the device.
 Simulator seems fine. I found this out when updating my beta 3
  iPhone
 to beta 5 yesterday. I downgraded back, but this beta
  unfortunately
 expires in 7 days on Aug 21, 2014.

 1. https://devforums.apple.com/message/1011583
 2.
   
  
 
 http://stackoverflow.com/questions/24882834/wkwebview-not-working-in-ios-8-beta-4/24922619#24922619
 3. https://issues.apache.org/jira/browse/CB-7288
 4. rdar://problem/17761459
 5. rdar://problem/17835098


 On Wed, Jul 16, 2014 at 12:05 PM, Marc Weiner 
  mhweiner...@gmail.com
   
wrote:
 Same! Shazron, you're awesome!!


 On Wed, Jul 16, 2014 at 2:08 PM, Carlos Santana 
   csantan...@gmail.com

 wrote:

 Happy to see good news when returning from vacation. :-)


 On Mon, Jul 7, 2014 at 10:33 PM, Ally Ogilvie 
  aogil...@wizcorp.jp
   
wrote:

  I'm usually an observer here but.. the urge to post was too
   great!
 
 

   
  
 
 http://seattlesportsnet.files.wordpress.com/2013/11/anchorman-celebration-gif.gif
 
  Thanks for the research Shaz.
 
  On Tue, Jul 8, 2014 at 4:57 AM, Tommy Williams 
   to...@devgeeks.org

 wrote:
 
   Yes!!!
   On 8 Jul 2014 05:52, Shazron shaz...@gmail.com wrote:
  
Good news:
https://twitter.com/shazron/status/486235098715394048
   
On Fri, Jun 27, 2014 at 3:46 PM, Shazron 
  shaz...@gmail.com
wrote:
 Broke the iOS 8 issue into sub-tasks:
 https://issues.apache.org/jira/browse/CB-7043



 On Mon, Jun 16, 2014 at 8:20 AM, Shazron 
   shaz...@gmail.com
 wrote:
 Haven't yet - but from what I read - no. Something
  about
requests
   being
out
 of process


 On Monday, June 16, 2014, Andrew Grieve 
agri...@chromium.org
  wrote:

 Awesome.

 Shaz (or anyone else), curious if you've tested yet
 to
   see

Re: Confused about Android API level and Cordova, does it support anything less than 19

[Brian LeRoux]

NEVER LET IT HAPPEN AGAIN

(jk)

np, Mark. also: API level should be backwards compat so having at 19 means
17 *should* work but please let us know if not!

On Wed, Sep 24, 2014 at 12:54 PM, Mark E. Scott Jr. msc...@scott-usa.com
wrote:

 Apologies for this, I misread the mailing list text at
 http://cordova.apache.org/#mailing-list, didn't realize that this was for
 development of Cordova, not developing with Cordova.

 Mark

 -Original Message-
 From: Mark E. Scott Jr. [mailto:msc...@scott-usa.com]
 Sent: Wednesday, September 24, 2014 2:49 PM
 To: dev@cordova.apache.org
 Subject: Confused about Android API level and Cordova, does it support
 anything less than 19

 So,

 If I have android API 19 installed, everything works fine, I can execute
 the command cordova platform add android.  However, to support the Galaxy
 S 3 devices we have for test, I need API level 17.  According to the
 Cordova docs for 3.5.0
 http://cordova.apache.org/docs/en/3.5.0/guide_platforms_android_index.md.html#Android%20Platform%20Guide,
 it supports  API level 10 and later.

 Things still worked when I added API level 17, but we noticed it was still
 using the API level 19.  Upon removing API level 19, I get the following
 error executing cordova platform add android.

 Error: Please install Android target 19 (the Android newest SDK). Make
 sure you have the latest Android tools installed as well. Run android
 from your command-line to install/update any missing SDKs or tools.
 at
 C:\Users\mscott\.cordova\lib\android\cordova\3.5.1\bin\lib\check_reqs.js:80:29
 at _fulfilled
 (C:\Users\mscott\.cordova\lib\android\cordova\3.5.1\bin\node_modules\q\q.js:798:54)
 at self.promiseDispatch.done
 (C:\Users\mscott\.cordova\lib\android\cordova\3.5.1\bin\node_modules\q\q.js:827:30)
 at Promise.promise.promiseDispatch
 (C:\Users\mscott\.cordova\lib\android\cordova\3.5.1\bin\node_modules\q\q.js:760:13)
 at
 C:\Users\mscott\.cordova\lib\android\cordova\3.5.1\bin\node_modules\q\q.js:574:44
 at flush
 (C:\Users\mscott\.cordova\lib\android\cordova\3.5.1\bin\node_modules\q\q.js:108:17)
 at process._tickCallback (node.js:419:13)
 Error: C:\Users\mscott\.cordova\lib\android\cordova\3.5.1\bin\create.bat:
 Command failed with exit code 8
 at ChildProcess.whenDone
 (D:\projects\mobile\EMS-Mobile\node_modules\cordova\node_modules\cordova-lib\src\cordova\superspawn.js:135:23)
 at ChildProcess.emit (events.js:98:17)
 at maybeClose (child_process.js:756:16)
 at Process.ChildProcess._handle.onexit (child_process.js:823:5)

 Does it, or does it not actually support earlier Android API levels?  Do I
 have to move to an earlier version of Cordova to support API level 17?

 I am using this in conjunction with phonegap, but was starting with the
 simple command of adding a platform.  I'm aware there is a preference for
 SDK level in the config.xml, but it didn't appear to have any affect on the
 cordova add platform command.

 I'm getting ready to add API 19 back in conjunction with the config.xml
 preferences in place, to see if it will compile with the right SDK tools in
 that scenario.

 Thanks!

 Mark E. Scott, Jr.
 msc...@scott-usa.com

Re: [DISCUSS] plugins release Sept 29

[Brian LeRoux]

Heh, now imagine a futuristic far off world where we could take Virtual
Automation and make it actually virtual.

#gamechanger #devops

On Tue, Sep 23, 2014 at 2:45 PM, Jesse purplecabb...@gmail.com wrote:

 Sounds great to me!
 Thanks for volunteering.

 I would also like to suggest that we attempt to publish any changed plugins
 every week, meaning a vote every Friday potentially.  This would make us so
 good at this vote+release process that it would become virtually automatic
 again, and we could even continually review or process and
 streamline/automate stuff.



 @purplecabbage
 risingj.com

 On Tue, Sep 23, 2014 at 2:30 PM, Marcel Kinard cmarc...@gmail.com wrote:

  If these Windows-universal-platform changes are deemed important, how
  about doing another plugins release starting the end of this week and
  ending with a go-live on Monday?
 
  If folks like this idea, I'm willing to be release manager for it.
 
  Any other iOS 8 content that should also be included?
 
  On Sep 19, 2014, at 3:01 PM, Jesse purplecabb...@gmail.com wrote:
 
   These have/are being merged, but nothing should block anything.
   If we need to release some plugins next week, then we can do that.
  Nothing
   should ever stop the train, if it doesn't make into this one it can go
 in
   the next one.
  
   @purplecabbage
   risingj.com
  
   On Fri, Sep 19, 2014 at 11:58 AM, Marcel Kinard cmarc...@gmail.com
  wrote:
  
   Ping. No other votes yet. So where are we at with this?
  
   On Sep 18, 2014, at 2:53 PM, Sergey Grebnov (Akvelon) 
   v-seg...@microsoft.com wrote:
  
   Hi, I'm still waiting for the following PRs to be reviewed/merged.
 Most
   of them are critical to have plugins working on Windows 8.1 and
 Windows
   Phone 8.1, so if they are not merged by my morning, I'll merge the
  fixes by
   myself since they are very local and affect windows only.
  
   Bugfixing related to new Windows universal platform
   https://github.com/apache/cordova-plugin-contacts/pull/43
   https://github.com/apache/cordova-plugin-contacts/pull/44
  
   https://github.com/apache/cordova-plugin-media/pull/26
  
   https://github.com/apache/cordova-plugin-media-capture/pull/25
   https://github.com/apache/cordova-plugin-media-capture/pull/26
  
   Improvement
   https://github.com/apache/cordova-plugin-inappbrowser/pull/53
  
   From what I can see, they have all been subsequently merged except
 this
   one:
   https://github.com/apache/cordova-plugin-media-capture/pull/26
  
   So Sergey, are you saying that these pull requests are blockers for
 the
   plugins release, and you want this vote thread cancelled and another
 one
   started that includes the merged pull requests listed above?
  
   On Sep 17, 2014, at 11:47 PM, Marcel Kinard cmarc...@gmail.com
 wrote:
  
   Please review and vote on the release of this plugins release.
  
   Compared to attempt #1, it includes a change to the geolocation
 plugin
   for FireOS. The tag for that repo was updated.
  
   Release issue: https://issues.apache.org/jira/browse/CB-7571
  
   The plugins have been published to dist/dev:
   https://dist.apache.org/repos/dist/dev/cordova/CB-7571/
  
   The packages were published from their corresponding git tags:
cordova-plugin-battery-status: 0.2.11 (c80ffae72f)
cordova-plugin-camera: 0.3.2 (af18483d69)
cordova-plugin-console: 0.2.11 (9d1c255ac7)
cordova-plugin-contacts: 0.2.13 (e42219a7d5)
cordova-plugin-device: 0.2.12 (c6e23d8a61)
cordova-plugin-device-motion: 0.2.10 (213aea947f)
cordova-plugin-device-orientation: 0.3.9 (a09ef3c4ff)
cordova-plugin-dialogs: 0.2.10 (64017132b4)
cordova-plugin-file: 1.3.1 (198ca6198e)
cordova-plugin-file-transfer: 0.4.6 (16249c2f7a)
cordova-plugin-geolocation: 0.3.10 (543afdf88a)
cordova-plugin-globalization: 0.3.1 (6c4798d263)
cordova-plugin-inappbrowser: 0.5.2 (8ce6b497fa)
cordova-plugin-media: 0.2.13 (b2e92f9396)
cordova-plugin-media-capture: 0.3.3 (5888a627f7)
cordova-plugin-network-information: 0.2.12 (df7aac845d)
cordova-plugin-splashscreen: 0.3.3 (e4d8b77027)
cordova-plugin-statusbar: 0.1.8 (6cce513237)
cordova-plugin-vibration: 0.3.11 (5adf530d36)
  
   Upon a successful vote I will upload the archives to dist/, upload
 them
   to the Plugins Registry, and post the corresponding blog post.
  
   Voting guidelines:
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
  
   Voting will go on for a minimum of 48 hours.
  
   I vote +1:
   * Ran coho audit-license-headers over the relevant repos
   * Ran coho verify-archive over the relevant repos
  
  
 
 

Re: [DISCUSS] shrinkwrap

[Brian LeRoux]

I'm w/ Mike on this. No idea why we started using shrinkwrap, its always
had a flaky rep, and if we don't remember why then I'm guessing we might
have decided to use it for reasons that may have been more defensive than
actually solving a problem we had. Lets turf it. If bugs get reported then
we can bring it back.

On Fri, Sep 19, 2014 at 9:37 AM, Marcel Kinard cmarc...@gmail.com wrote:


 On Sep 18, 2014, at 1:32 PM, Parashuram Narasimhan (MS OPEN TECH) 
 panar...@microsoft.com wrote:

  If we do have shrinkwrap in git at all times, who would be responsible
 for updating not only the versions of our dependencies, but also the
 dependencies of these dependencies?

 One thought on this is that the release manager could do it at the
 beginning of a new release on master, separate from the tagged/branched
 release that is being packaged for release. Similar to how we add a -dev
 suffix, that's when there could be a systemic refresh. And of course, if a
 developer finds a technical driver to refresh the dependents and shrinkwrap
 in the middle of a dev cycle, it would happen there too.

  Why should cordova-lib and cordova-plugman not have shrinkwraps? Not all
 tools use cordova-cli as a way to build cordova apps. There were also
 discussions about using cordova-lib being the public API to build apps. If
 that is the case, judging by our shrinkwrap philosophy, we need that file
 on all repos that we say are public API.

 My thinking is that since a shrinkwrap is fully recursive, only the
 top-level package needs to have the shrinkwrap. If there is a separate
 third-party app that uses cordova-lib, they can choose whether or not to
 have a shrinkwrap, and it wouldn't be partially forced on them by its
 presence inside cordova-lib.  Well, and it's also a pain for us to generate
 shrinkwraps inside our own dependencies.

Re: [DISCUSS] shrinkwrap

[Brian LeRoux]

So I think its neat we had a vote but was there a technical reason for it?
Nope. Lets kill it.


On Fri, Sep 19, 2014 at 11:23 AM, Carlos Santana csantan...@gmail.com
wrote:

 @Brian shrinkwrap was implemented in the release process because it was
 discuss in the mailing list and agreed, no -1 votes
 http://markmail.org/thread/j6bv5bk5ndlokobj

 can someone show me a jira issue or contributor having problems with having
 npm-shrinkwrap.json in the npm package only?


 On Fri, Sep 19, 2014 at 1:30 PM, Brian LeRoux b...@brian.io wrote:

  I'm w/ Mike on this. No idea why we started using shrinkwrap, its always
  had a flaky rep, and if we don't remember why then I'm guessing we might
  have decided to use it for reasons that may have been more defensive than
  actually solving a problem we had. Lets turf it. If bugs get reported
 then
  we can bring it back.
 
  On Fri, Sep 19, 2014 at 9:37 AM, Marcel Kinard cmarc...@gmail.com
 wrote:
 
  
   On Sep 18, 2014, at 1:32 PM, Parashuram Narasimhan (MS OPEN TECH) 
   panar...@microsoft.com wrote:
  
If we do have shrinkwrap in git at all times, who would be
 responsible
   for updating not only the versions of our dependencies, but also the
   dependencies of these dependencies?
  
   One thought on this is that the release manager could do it at the
   beginning of a new release on master, separate from the tagged/branched
   release that is being packaged for release. Similar to how we add a
  -dev
   suffix, that's when there could be a systemic refresh. And of course,
 if
  a
   developer finds a technical driver to refresh the dependents and
  shrinkwrap
   in the middle of a dev cycle, it would happen there too.
  
Why should cordova-lib and cordova-plugman not have shrinkwraps? Not
  all
   tools use cordova-cli as a way to build cordova apps. There were also
   discussions about using cordova-lib being the public API to build apps.
  If
   that is the case, judging by our shrinkwrap philosophy, we need that
 file
   on all repos that we say are public API.
  
   My thinking is that since a shrinkwrap is fully recursive, only the
   top-level package needs to have the shrinkwrap. If there is a separate
   third-party app that uses cordova-lib, they can choose whether or not
 to
   have a shrinkwrap, and it wouldn't be partially forced on them by its
   presence inside cordova-lib.  Well, and it's also a pain for us to
  generate
   shrinkwraps inside our own dependencies.
 



 --
 Carlos Santana
 csantan...@gmail.com