Re: Looking forward to contribute | Introducing myself

I would love to share my experience on plugin development. I had a look at the wiki and I need to whether there are any existing docs on plugin development, in case I have missed. And if I am writing one, where I should be adding that ? On Tue, Feb 4, 2014 at 5:27 AM, Marcel Kinard wrote: > Wel

Re: Dropping iOS 5.0 support

Bump. Didn't see a solid statement here but... As a developer for the commercial machine we launched a game in Asia Q4 2013 and with a now sizeable amount of users: iOS 5.1 is 1% of total users. +1 drop support for version < 6.0. On Sat, Dec 21, 2013 at 10:02 AM, Shazron wrote: > I think t

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

It sounds like a good plan indeed. I would encourage our users to migrate to the new locations as soon as they can. 12 months is an acceptable migration window I believe. +1 to Ian's proposal. On Wed, Feb 5, 2014 at 1:43 PM, Jesse wrote: > +1 to Ian's proposal > > @purplecabbage > risingj.com

Re: Need to revert a CLI breaking change causing CB-5957

I'd be more than happy to provision some WP8 dev devices. Please let me know who would need one (I am not sure how many I can get but will do my best) and didn't already get one at last phonegap day 😊 Note that having actual devices for testing do not prevent from having to install Visual Studio

Re: Need to revert a CLI breaking change causing CB-5957

Andrew, Didn’t you get a phone at PhoneGap Day? Were you too much of a “presenter” at the workshop to get one? ;) If I ever get around to getting set up for WP8 I will try and help test… will probably happen after I finish our Blackberry10 port. - tommy On 6 Feb 2014, at 9:00 am, Andrew Griev

Re: Fw: HTML5 in latest "Developer Economics" survey

ya for some reason ppl like to call us 'hybrid apps' which not a term I love but I guess it suffices anyhow, seems like we're in good shape market opportunity wise [1] [1] http://www.gartner.com/newsroom/id/2324917 On Wed, Feb 5, 2014 at 1:51 PM, Lisa Seacat DeLuca wrote: > Interesting take on

Re: Need to revert a CLI breaking change causing CB-5957

Just to be clear - it's not enough to test on windows, this breaks only for windows phone / win8 I think. That said, I've recently got set up with VMs and modern.ie. Is that enough to test out Hello World on a WP emulator? On Wed, Feb 5, 2014 at 4:03 PM, Michal Mocny wrote: > First off, Jesse

Fw: HTML5 in latest “Developer Economics” survey

Interesting take on mobile development and HTML5 from the w3c web and mobile interest group mailing list... I don't see any references to Cordova or Phonegap in the article. Lisa Seacat DeLuca Twitter: @LisaSeacat ldel...@apache.org ldel...@us.ibm.com - Forwarded by Lisa Seacat DeLuca/San

Re: input type=file broken on Android 4.4

Sounds good. Yeah, most of our quirks are documented in the plugin docs at the moment. Upgrade guide sounds fine to me though. We could have a top-level "Platform Quirks" section if we put some effort into listing them all... but I'm not signing up... On Wed, Feb 5, 2014 at 12:48 PM, Mike Billau

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

+1 to Ian's proposal @purplecabbage risingj.com On Wed, Feb 5, 2014 at 1:33 PM, Andrew Grieve wrote: > Joe - I appreciate your effort and your input, but I don't appreciate > hostility on this list from anyone, including you. > This is a public list, and I see nothing wrong with sebb's email i

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

Joe - I appreciate your effort and your input, but I don't appreciate hostility on this list from anyone, including you. This is a public list, and I see nothing wrong with sebb's email in this thread. If you are at the point that you don't want to receive emails from sebb, then I would ask that yo

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

I think this approach is our best path forward right now. There's no immediate need to break apps for developers; it was a convenient time in the development of the plugin, but we can easily wait for another convenient time. There seems to be no compelling reason to couple a breaking change with th

Re: [Android] SecureToken/NoFrak feature addition

On Fri, Jan 31, 2014 at 5:50 PM, Andrew Grieve wrote: > After thinking a bit more, I think it is not completely crazy for the > top-level frame to be navigated to a malicious host. Quite easy actually, > "frame busting" is a thing. > > So... idea the third: > Instead of using the whitelist, we use

Re: Need to revert a CLI breaking change causing CB-5957

First off, Jesse I appreciate your respectable tone here, thank you. I agree, this is a sign that we generally don't test nearly enough on windows, and should fix that. As someone who also reviewed the work Mark was doing here, sorry this wasn't caught. I'll just add that I think the tests shoul

Re: Need to revert a CLI breaking change causing CB-5957

I would think it would be enough to just make sure that : 1. our tests catch the issue 2. the tests are run on windows/mac/linux before an npm publish I agree Mark, the change is valuable, and I don't mean to single you out. I am just concerned about how it made it to npm while obviously broken on

Re: [Android] Deprecation of Geolocation on Android

We need to zero out the implementation so that it's just a config.xml on Android. Do we have an issue tracking this? On Wed, Feb 5, 2014 at 11:19 AM, Mike Billau wrote: > So, any resolution on this? Anything special we need to do regarding the > deprecation notice since we're not actually deprec

Re: Need to revert a CLI breaking change causing CB-5957

Some CI for plugman and CLI on Windows would be extremely useful. I just looked briefly at Travis-CI, but they only have Linux and OS X. Here is a random Windows based service I just found http://ww

Re: [Android] Deprecation of Geolocation on Android

So, any resolution on this? Anything special we need to do regarding the deprecation notice since we're not actually deprecating the plugin itself (need it to add the permissions) but rather just our implementation? On Tue, Jan 14, 2014 at 2:58 PM, Mike Billau wrote: > +1 to deprecate. Tested W

Re: Need to revert a CLI breaking change causing CB-5957

I'm going to agree with Jesse. That commit should not have made it out to the wild without a platform tag increase. It is fine to go out for 3.4. Either we take the commit out and release the CLI again or we revert the CLI to two versions ago (3.3.1-0.2.0) and focus on getting 3.4.0. Thoughts?

RE: Need to revert a CLI breaking change causing CB-5957

Is there a way we could have a continuous integration process for the CLI too ? -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, February 5, 2014 9:54 AM To: dev@cordova.apache.org Subject: Need to revert a CLI breaking change causing CB-5957 WP8+7 and Win

Re: input type=file broken on Android 4.4

Resurrecting this thread. The problem is that input type="file" does not show a file picker dialog; this is a problem with Chromium on Android and you can see that even the Chrome browser can't handle this either. I think we should just document this as an Android Quirk and wait for it to be fixed

Need to revert a CLI breaking change causing CB-5957

WP8+7 and Windows8 users are currently unable to create new projects with the CLI because this commit [1] has shipped. Here is an issue raised on the subject [2] While I have addressed the issue by adding the namespace to the tag in the platform create templates for the affected platforms, until

Re: Get Mac address from iPhone and Android

That wasn't what he asked, and the question from SO was about access point MAC addresses. In any case, this is the wrong list for these sort of questions. On Wed, Feb 5, 2014 at 8:58 AM, Zach W wrote: > So the solution > here< > http://stackoverflow.com/questions/11427449/how-to-get-mac-address

Re: Get Mac address from iPhone and Android

So the solution herewill no longer work? Or maybe I'm missing something and that's not even an appropriate solution (but it's worked for me). On Fri, Jan 31, 2014 at 9:20 AM, Shazron wrote: > Sadly for iO

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

Agreed! I didn't see that either until now. On Wed, Feb 5, 2014 at 8:04 AM, Tommy Williams wrote: > Of course, while writing my rant, Ian has summarized a great proposal. > > +1 to the below! > On 06/02/2014 2:51 am, "Ian Clelland" wrote: > >> On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny wrote

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

Of course, while writing my rant, Ian has summarized a great proposal. +1 to the below! On 06/02/2014 2:51 am, "Ian Clelland" wrote: > On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny wrote: > > > Honestly, my opinion on this: Leave the default as-is for now. We've > just > > made huge changes to

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

I couldn't have said it better myself. -1 to "just break it". On Wed, Feb 5, 2014 at 8:00 AM, Tommy Williams wrote: > -1 to "just break it" > > Developers using Cordova still are frequently having to deal with massive > breaking changes every few releases. Developing and (even more so) > maintai

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

Can you please leave this list sebb? You opinion is unwelcome! On Wed, Feb 5, 2014 at 6:05 AM, sebb wrote: > On 5 February 2014 13:20, David Kemp wrote: >> -1 to merging reads. That just sounds like a horrible thing to debug. > > Seems to me that developers using the plugin will have to implemen

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

-1 to "just break it" Developers using Cordova still are frequently having to deal with massive breaking changes every few releases. Developing and (even more so) maintaining an app built using Cordova is actually pretty painful sometimes... Even for me, and I am on this list and see this stuff co

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny wrote: > Honestly, my opinion on this: Leave the default as-is for now. We've just > made huge changes to the API, which may have bugs / implications we haven't > fully thought through. That's a really good point. If we do this right now, we have t

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

On Wed, Feb 5, 2014 at 10:29 AM, Anis KADRI wrote: > I also think we should break it now. It's not as if we have never broken > anything before... keeping backward compatibility should anyways be > preferred but in this case I think it would cause more trouble than it > would solve. > I say don't

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

I also think we should break it now. It's not as if we have never broken anything before... keeping backward compatibility should anyways be preferred but in this case I think it would cause more trouble than it would solve. I say don't write any migration tools but document the changes in plugin.x

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

Honestly, my opinion on this: Leave the default as-is for now. We've just made huge changes to the API, which may have bugs / implications we haven't fully thought through. Lets let a subset of users upgrade to the new $MAJOR version, and a subset of those add the new preference. In a later rele

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

Imagine a hypothetical implementation which works like this: Consumer asks for a file, we don't find it in Library, nor is the "we're migrating file", we create the "we're migrating file", it's present in ‎Root. We start a copy in the background and return some file handle (probably a proxy). A

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

On 5 February 2014 14:55, David Kemp wrote: > My concern with any automated fix is that we have no idea what files belong > to an app. > The default is to just toss everything in the root. > Files may be user data that is shared between apps, config files or temp > files. The developer probably kn

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref wrote: > Is it impossible to have reads merged from both locations, but writes go > to the new location, and when a write completes in the new location, delete > the old one? It might be. The File API doesn't impose any sort of model for read/write pa

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

My concern with any automated fix is that we have no idea what files belong to an app. The default is to just toss everything in the root. Files may be user data that is shared between apps, config files or temp files. The developer probably knows what to migrate - we don't.\ On Wed, Feb 5, 2014

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

On 5 February 2014 13:20, David Kemp wrote: > -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting i

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

-1 to merging reads. That just sounds like a horrible thing to debug. +1 to 'go big or go home'. Break it now. Break it obviously. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref wrote: > Is it impossible to have reads merged from both locations, but writes go > to the new location, and when a writ