Re: Looking forward to contribute | Introducing myself

[Asanka Nissanka]

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:

> Welcome! A great starting point is
> http://wiki.apache.org/cordova/ContributorWorkflow
>
> One of the things I've been interested in is a "Plugin Development Guide"
> being added to the docs. Would you have interest in sharing your experience
> with other potential plugin developers?
>
>

Re: Dropping iOS 5.0 support

[Ally Ogilvie]

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 that last paragraph is key - let's provide instructions in a doc in
> cordova-ios/guides if they need this support. Not sure we need this in
> cordova-docs
>
>
> On Fri, Dec 20, 2013 at 6:15 AM, Andrew Grieve 
> wrote:
>
> > I think we'd be fine to drop "official support" for iOS 5, but as has
> been
> > pointed out, there's very little code-wise that would change.
> >
> > If bug reports come that say "this function is being called and it
> doesn't
> > exist on iOS 5", then that's a trivial fix. Likely devs will just fix it
> > themselves anyways.
> >
> > If devs want to deploy for iOS 5, I think they'll be able to fiddle with
> > their Xcode deployment target settings and do so fairly easily even if we
> > "drop support for it". They are better at testing their own apps anyways.
> >
> >
> >
> >
> >
> > On Fri, Dec 20, 2013 at 7:00 AM, Josh Soref 
> wrote:
> >
> > > Fwiw, If you have your installation media, getting 10.8/10.9 to install
> > in
> > > the latest version of VirtualBox is trivial. I believe that the same
> > > applies to 10.7, but I can't find my installation media :(.
> > > -
> > > This transmission (including any attachments) may contain confidential
> > > information, privileged material (including material protected by the
> > > solicitor-client or other applicable privileges), or constitute
> > non-public
> > > information. Any use of this information by anyone other than the
> > intended
> > > recipient is prohibited. If you have received this transmission in
> error,
> > > please immediately reply to the sender and delete this information from
> > > your system. Use, dissemination, distribution, or reproduction of this
> > > transmission by unintended recipients is not authorized and may be
> > unlawful.
> > >
> >
>



-- 
Ally Ogilvie
Lead Developer - MobDev. | Wizcorp Inc. 
--
TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 |
Website
 | Twitter  |
Facebook
 | LinkedIn 

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

[Anis KADRI]

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
>
>
> 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 in this
> > thread.
> > If you are at the point that you don't want to receive emails from sebb,
> > then I would ask that you choose to ignore them, or to create an email
> > filter on your end.
> >
> > +1 to Ian's proposal.
> >
> >
> > On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser  wrote:
> >
> > > 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 implement
> > > > something similar in order to make it easier for their users.
> > > >
> > > > Would it not be better to spend the time getting it right once, for
> > > > the benfit of all developers, rather than hoping they each get it
> > > > right?
> > > >
> > > > I don't know what is involved here, so this is theoretical.
> > > > But I believe that compatibility should only be broken if necessary.
> > > > Also that fixing a problem at source is usually a lot cheaper than
> > > > requiring downstream developers/users to do so.
> > > > There are lots more of them, so any extra effort they have to expend
> > > > is multiplied many times.
> > > > In other words, the cost-benefit should not just look at the
> immediate
> > > > cost to the project.
> > > >
> > > >> +1 to 'go big or go home'. Break it now. Break it obviously.
> > > >
> > > > But I agree that breakage - if decided on - should be obvious.
> > > >
> > > >>
> > > >> 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?
> > >
> >
>

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

[Olivier Bloch (MS OPEN TECH)]

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 and the WP SDK. Also you can make the emulator work 
within a VM.
I am working with Mike Sierra on getting the WP and Windows platforms doc 
updated with instructions on how to get this to work.

Olivier

Sent from Windows Mail

From: Tommy-Carlos Williams
Sent: ‎Wednesday‎, ‎February‎ ‎5‎, ‎2014 ‎2‎:‎16‎ ‎PM
To: dev@cordova.apache.org

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 Grieve  wrote:

> 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 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 should have been run before the
>> *tooling release* (and even better, on a regular basis with CI as stated),
>> not necessarily before every patch to tip of tree lands.  The majority of
>> changes do not affect specific platforms in subtle ways -- and while we
>> should absolutely have process to catch those that do -- any process that
>> involves manually testing in multiple configurations for every single patch
>> is prohibitive and I think unrealistic.
>>
>> That change was committed a month ago -- how did we not catch it before
>> release?
>>
>> To decrease the odds of this happening again, perhaps we need to amend the
>> steps for tooling release (
>> http://wiki.apache.org/cordova/StepsForToolsRelease) to ensure testing on
>> all the platforms?
>>
>> -Michal
>>
>>
>> On Wed, Feb 5, 2014 at 2:34 PM, Jesse  wrote:
>>
>>> 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
>>> windows devices.
>>>
>>> @purplecabbage
>>> risingj.com
>>>
>>>
>>> On Wed, Feb 5, 2014 at 11:22 AM, Mark Koudritsky 
>>> wrote:
>>>
 Some CI for plugman and CLI on Windows would be extremely useful. I
>> just
 looked briefly at Travis-CI<
 http://docs.travis-ci.com/user/getting-started/>,
 but they only have Linux and OS
 X.
 Here is a random Windows based service I just found
 http://www.appveyor.com/,
 didn't check if it's usable for our case. Of course, this solution
>> would
 only be for the host side tools, not for on-device tests which are the
>>> most
 important ones.

 That commit was part of this review
  dealing
 with CB-4153 . But
>> since
 the
 patch (probably prepared with git format-patch) contained two separate
 commits and the second one didn't have a reference to the bug, there is
>>> no
 way to deduce that reference. The lesson for me is to add CB-:
>> prefix
 to each commit message in a series of related commits. The check was
>>> added
 to verity that config.xml does look like it's a Cordova related
 config.xlmbecause with the new --link-to tag a random file named
 config.xml by chance could be sitting in that www dir.


 On Wed, Feb 5, 2014 at 2:14 PM, Steven Gill 
 wrote:

> 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?
>
>
> On Wed, Feb 5, 2014 at 10:41 AM, Parashuram Narasimhan (MS OPEN
>> TECH) <
> panar...@microsoft.com> wrote:
>
>> 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.apach

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

[Tommy-Carlos Williams]

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 Grieve  wrote:

> 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 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 should have been run before the
>> *tooling release* (and even better, on a regular basis with CI as stated),
>> not necessarily before every patch to tip of tree lands.  The majority of
>> changes do not affect specific platforms in subtle ways -- and while we
>> should absolutely have process to catch those that do -- any process that
>> involves manually testing in multiple configurations for every single patch
>> is prohibitive and I think unrealistic.
>> 
>> That change was committed a month ago -- how did we not catch it before
>> release?
>> 
>> To decrease the odds of this happening again, perhaps we need to amend the
>> steps for tooling release (
>> http://wiki.apache.org/cordova/StepsForToolsRelease) to ensure testing on
>> all the platforms?
>> 
>> -Michal
>> 
>> 
>> On Wed, Feb 5, 2014 at 2:34 PM, Jesse  wrote:
>> 
>>> 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
>>> windows devices.
>>> 
>>> @purplecabbage
>>> risingj.com
>>> 
>>> 
>>> On Wed, Feb 5, 2014 at 11:22 AM, Mark Koudritsky 
>>> wrote:
>>> 
 Some CI for plugman and CLI on Windows would be extremely useful. I
>> just
 looked briefly at Travis-CI<
 http://docs.travis-ci.com/user/getting-started/>,
 but they only have Linux and OS
 X.
 Here is a random Windows based service I just found
 http://www.appveyor.com/,
 didn't check if it's usable for our case. Of course, this solution
>> would
 only be for the host side tools, not for on-device tests which are the
>>> most
 important ones.
 
 That commit was part of this review
  dealing
 with CB-4153 . But
>> since
 the
 patch (probably prepared with git format-patch) contained two separate
 commits and the second one didn't have a reference to the bug, there is
>>> no
 way to deduce that reference. The lesson for me is to add CB-:
>> prefix
 to each commit message in a series of related commits. The check was
>>> added
 to verity that config.xml does look like it's a Cordova related
 config.xlmbecause with the new --link-to tag a random file named
 config.xml by chance could be sitting in that www dir.
 
 
 On Wed, Feb 5, 2014 at 2:14 PM, Steven Gill 
 wrote:
 
> 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?
> 
> 
> On Wed, Feb 5, 2014 at 10:41 AM, Parashuram Narasimhan (MS OPEN
>> TECH) <
> panar...@microsoft.com> wrote:
> 
>> 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 Windows8 users are currently unable to create new
>> projects
>> WP8+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
>> 3.4.0 ships this will continue to break.
>> 
>> I am unhappy about how this landed without discussion, or an issue
>> in
>> jira, but ultimately this is just a symptom of the fact that not
>>> enough

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

[Brian LeRoux]

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 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 Francisco/IBM on 02/05/2014
> 04:48 PM -
>
> From:   Dominique Hazael-Massieux 
> To: public-web-mob...@w3.org
> Date:   02/05/2014 09:25 AM
> Subject:HTML5 in latest "Developer Economics" survey
>
>
>
> Hi,
>
> VisionMobile has released the latest edition of their survey of mobile
> developers:
> http://www.visionmobile.com/blog/2014/02/developer-economics-q1-2014/
>
> I've gone through it and noted the following interesting bits regarding
> "HTML5":
> * "HTML5 sits between iOS and Android in terms of developers
> below the app poverty line (59% below the line) and has a middle
> class that is roughly equal to Android. However, it boasts the
> largest share of publishers that generate very-high revenues
> (over $50k per app/month)."
>
> *  "The ability to reach users remains the single most important
> platform selection criterion, highlighted by 57% of developers
> as very important. Revenue potential comes in as the fifth most
> important selection criterion, marked as very important by 44%
> of developers"
>
> * "The appeal of HTML5 as a priority platform for app
> development is restricted to those use cases where it excels:
> cross-screen and cross-platform deployment."
>
> * "HTML5 can be viewed as both a deployment platform
> (on-browser) and a technology that can be used beyond the
> browser (off-browser)"
>
> * "HTML5 is still far off from being an app ecosystem as it
> lacks distribution, retailing and monetisation services in the
> form of a large-scale app store [...] In spite of these issues,
> HTML5 remains a very attractive cross-platform development route
> for developers, 16% of whom indicate their intention to adopt
> the platform."
>
> * "HTML5 is the priority platform for 14% of mobile developers,
> down from 17% in Q3 2013. Although this slump is marginal, it is
> likely that developers that prioritised HTML5 previously have
> come to terms with the shortcomings of pure web approaches."
>
> * "While HTML5 is very close to iOS in terms of developer
> mindshare, usage of HTML5 as a primary platform is quite low,
> indicating that the majority of HTML5 users view it as a
> companion, rather than a priority platform. Lacking large-scale
> discovery, monetisation and distribution functions, HTML5
> continues to be a technology platform rather than a
> fully-fledged app ecosystem."
>
> * "Our research on HTML5 vs native apps in Q3 2013 showed that
> the key issue in HTML5 development, is not performance or API
> reach, but the lack of mature development tools."
>
> * "among those developing primarily on iOS or Android, about 19%
> use HTML5 to display limited web content in their apps, for
> example documentation or elements that may require frequent
> updating. [...] At the same time around 10% of developers
> targeting Android or iOS use HTML5 to develop hybrid apps, using
> tools such as PhoneGap."
>
> I've added those to the relevant sections in
> https://www.w3.org/wiki/Mobile/articles
>
> Dom
>
>
>
>
>

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

[Andrew Grieve]

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 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 should have been run before the
> *tooling release* (and even better, on a regular basis with CI as stated),
> not necessarily before every patch to tip of tree lands.  The majority of
> changes do not affect specific platforms in subtle ways -- and while we
> should absolutely have process to catch those that do -- any process that
> involves manually testing in multiple configurations for every single patch
> is prohibitive and I think unrealistic.
>
> That change was committed a month ago -- how did we not catch it before
> release?
>
> To decrease the odds of this happening again, perhaps we need to amend the
> steps for tooling release (
> http://wiki.apache.org/cordova/StepsForToolsRelease) to ensure testing on
> all the platforms?
>
> -Michal
>
>
> On Wed, Feb 5, 2014 at 2:34 PM, Jesse  wrote:
>
> > 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
> > windows devices.
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Wed, Feb 5, 2014 at 11:22 AM, Mark Koudritsky 
> > wrote:
> >
> > > Some CI for plugman and CLI on Windows would be extremely useful. I
> just
> > > looked briefly at Travis-CI<
> > > http://docs.travis-ci.com/user/getting-started/>,
> > > but they only have Linux and OS
> > > X.
> > > Here is a random Windows based service I just found
> > > http://www.appveyor.com/,
> > > didn't check if it's usable for our case. Of course, this solution
> would
> > > only be for the host side tools, not for on-device tests which are the
> > most
> > > important ones.
> > >
> > > That commit was part of this review
> > >  dealing
> > > with CB-4153 . But
> since
> > > the
> > > patch (probably prepared with git format-patch) contained two separate
> > > commits and the second one didn't have a reference to the bug, there is
> > no
> > > way to deduce that reference. The lesson for me is to add CB-:
> prefix
> > > to each commit message in a series of related commits. The check was
> > added
> > > to verity that config.xml does look like it's a Cordova related
> > > config.xlmbecause with the new --link-to tag a random file named
> > > config.xml by chance could be sitting in that www dir.
> > >
> > >
> > > On Wed, Feb 5, 2014 at 2:14 PM, Steven Gill 
> > > wrote:
> > >
> > > > 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?
> > > >
> > > >
> > > > On Wed, Feb 5, 2014 at 10:41 AM, Parashuram Narasimhan (MS OPEN
> TECH) <
> > > > panar...@microsoft.com> wrote:
> > > >
> > > > > 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 Windows8 users are currently unable to create new
> projects
> > > > > WP8+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
> > > > > 3.4.0 ships this will continue to break.
> > > > >
> > > > > I am unhappy about how this landed without discussion, or an issue
> in
> > > > > jira, but ultimately this is just a symptom of the fact that not
> > enough
> > > > > people test on WP7+8 and Windows 8.
> > > > > Please try to test all platforms before landing changes to
> > cordova-cli,
> > > > > cordova-plugman and cordova-js or at least tread lightly and try to
> > > aware
> > > > > of the impact outside of your pet platforms.  I am a

Fw: HTML5 in latest “Developer Economics” survey

[Lisa Seacat DeLuca]

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 Francisco/IBM on 02/05/2014 
04:48 PM -

From:   Dominique Hazael-Massieux 
To: public-web-mob...@w3.org
Date:   02/05/2014 09:25 AM
Subject:HTML5 in latest “Developer Economics” survey



Hi,

VisionMobile has released the latest edition of their survey of mobile
developers:
http://www.visionmobile.com/blog/2014/02/developer-economics-q1-2014/

I've gone through it and noted the following interesting bits regarding
“HTML5”:
* “HTML5 sits between iOS and Android in terms of developers
below the app poverty line (59% below the line) and has a middle
class that is roughly equal to Android. However, it boasts the
largest share of publishers that generate very-high revenues
(over $50k per app/month).”
 
*  ”The ability to reach users remains the single most important
platform selection criterion, highlighted by 57% of developers
as very important. Revenue potential comes in as the fifth most
important selection criterion, marked as very important by 44%
of developers” 
 
* “The appeal of HTML5 as a priority platform for app
development is restricted to those use cases where it excels:
cross-screen and cross-platform deployment.”
 
* “HTML5 can be viewed as both a deployment platform
(on-browser) and a technology that can be used beyond the
browser (off-browser)”
 
* “HTML5 is still far off from being an app ecosystem as it
lacks distribution, retailing and monetisation services in the
form of a large-scale app store […] In spite of these issues,
HTML5 remains a very attractive cross-platform development route
for developers, 16% of whom indicate their intention to adopt
the platform.”
 
* “HTML5 is the priority platform for 14% of mobile developers,
down from 17% in Q3 2013. Although this slump is marginal, it is
likely that developers that prioritised HTML5 previously have
come to terms with the shortcomings of pure web approaches.”
 
* “While HTML5 is very close to iOS in terms of developer
mindshare, usage of HTML5 as a primary platform is quite low,
indicating that the majority of HTML5 users view it as a
companion, rather than a priority platform. Lacking large-scale
discovery, monetisation and distribution functions, HTML5
continues to be a technology platform rather than a
fully-fledged app ecosystem.”
 
* “Our research on HTML5 vs native apps in Q3 2013 showed that
the key issue in HTML5 development, is not performance or API
reach, but the lack of mature development tools.” 
 
* “among those developing primarily on iOS or Android, about 19%
use HTML5 to display limited web content in their apps, for
example documentation or elements that may require frequent
updating. […] At the same time around 10% of developers
targeting Android or iOS use HTML5 to develop hybrid apps, using
tools such as PhoneGap.” 

I've added those to the relevant sections in
https://www.w3.org/wiki/Mobile/articles

Dom

Re: input type=file broken on Android 4.4

[Andrew Grieve]

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  wrote:

> 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 in the WebView because:
> 1. We don't want to build a file picker UI and have to maintain that
> 2. The bug seems fixed in Chrome Beta so hopefully the fix will make it
> into the WebView soon
> 3. There are probably a few different ways people can handle this with
> File/FileTransfer and the solution might be different for everyone
>
> One secondary issue is: Where to add this documentation? There isn't an
> overall "Android Platform Quirks" section, so we could either add this as
> an additional guide under Android, or add it in the Android Upgrade Guide
> [1], or just a blog post. Personally I think adding a new guide is too much
> overhead and would perfer to stick the notice in the Upgrade Guide by the
> first version of Cordova that supported 4.4. If nobody has any objections,
> I'll add a quirk note to the Upgrading Guide, section "Updating to 3.2 from
> 3.1"
>
> Here is the text I want to use:
> "Starting on Android 4.4, creating a file input element with type="file"
> will not open the file picker dialog.
> This is a regression with Chromium on Android and the problem can be
> reproduced in the standalone Chrome browser on Android (see
> http://code.google.com/p/android/issues/detail?id=62220)  The suggested
> workaround is to use the FileTransfer and File plugins for Android 4.4. You
> can listen for an onClick event from the input type="file" and then pop up
> a file picker UI. In order to tie the form data with the upload, you can
> use JavaScript to attach form values to the multi-part POST request that
> FileTransfer makes."
>
>
> [1]
>
> http://cordova.apache.org/docs/en/edge/guide_platforms_android_upgrading.md.html#Upgrading%20Android
>
>
>
>
>
>
> On Fri, Nov 15, 2013 at 11:34 PM, James Jong  wrote:
>
> > Ugh... hopefully there's a better solution.
> > -James Jong
> >
> > On Nov 14, 2013, at 2:10 PM, Brian LeRoux  wrote:
> >
> > > Ugly indeed but that is what we do! =)
> > >
> > > Probably just a docs issue doing what you describe.
> > >
> > >
> > > On Thu, Nov 14, 2013 at 10:57 AM, Andrew Grieve  > >wrote:
> > >
> > >> I'll ask around and see if anyone has ideas on fixing it.
> > >>
> > >> We could probably polyfill it though, by having a click handler on the
> > body
> > >> looking for clicks on , and then hijacking the
> > onsubmit()
> > >> of the form. Ugly.
> > >>
> > >>
> > >> On Thu, Nov 14, 2013 at 12:09 PM, Brian LeRoux  wrote:
> > >>
> > >>> I think it is reasonable that we choose to allow a polyfill for this
> > >>> regardless of the Google stance. The change is very likely to break
> > >>> existing users and just b/c it was 'private' doesn't mean that it
> > wasn't
> > >>> exposed. Maybe this is just a docs issue given we have the
> scaffolding
> > to
> > >>> fix this with File/FileTransfer.
> > >>>
> > >>> ??
> > >>>
> > >>>
> > >>> On Thu, Nov 14, 2013 at 8:39 AM, Joe Bowser 
> wrote:
> > >>>
> >  Apologize and say "Sorry, the Android team hates Cordova"?
> > 
> >  Honestly, was this a private API that was in the Android Browser
> code?
> >  If so, then we should assume that this would break, since this
> wasn't
> >  referenced in the Android APIs.  This is outside our scope, and we
> >  really can't do anything more with this without even more breakage.
> > 
> >  On Thu, Nov 14, 2013 at 8:26 AM, Mike Billau  >
> >  wrote:
> > > Hi everyone,
> > >
> > > This ticket[1] came in pretty recently talking about how input
> > >>> type=file
> > > does not work with Android 4.4 anymore, regardless of what your
> > >> target
> >  SDK
> > > is.
> > >
> > > Apparently this was a conscious design decision by Android [2].
> > >
> > > Does anybody have ideas on how we can fix this? Is this even in our
> >  scope?
> > > From what I can gather, we have always had to override certain
> > >> 'hidden'
> > > (yet public) methods on CordovaChromeClient [3] to enable input
> >  type=file.
> > > I'm thinking that either Android made this a private method or they
> > >>> just
> > > changed the method signature again. If they just changed the method
> > > signature, hopefully the new one will surface pretty soon and we
> can
> >  adjust
> > > CordovaChromeClient (I tried looking around in Android source but
> got
> > > pretty lost pretty quick...)
> > >
> > > Just wanted 

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

[Jesse]

+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 in this
> thread.
> If you are at the point that you don't want to receive emails from sebb,
> then I would ask that you choose to ignore them, or to create an email
> filter on your end.
>
> +1 to Ian's proposal.
>
>
> On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser  wrote:
>
> > 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 implement
> > > something similar in order to make it easier for their users.
> > >
> > > Would it not be better to spend the time getting it right once, for
> > > the benfit of all developers, rather than hoping they each get it
> > > right?
> > >
> > > I don't know what is involved here, so this is theoretical.
> > > But I believe that compatibility should only be broken if necessary.
> > > Also that fixing a problem at source is usually a lot cheaper than
> > > requiring downstream developers/users to do so.
> > > There are lots more of them, so any extra effort they have to expend
> > > is multiplied many times.
> > > In other words, the cost-benefit should not just look at the immediate
> > > cost to the project.
> > >
> > >> +1 to 'go big or go home'. Break it now. Break it obviously.
> > >
> > > But I agree that breakage - if decided on - should be obvious.
> > >
> > >>
> > >> 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?
> >
>

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

[Andrew Grieve]

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 you choose to ignore them, or to create an email
filter on your end.

+1 to Ian's proposal.


On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser  wrote:

> 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 implement
> > something similar in order to make it easier for their users.
> >
> > Would it not be better to spend the time getting it right once, for
> > the benfit of all developers, rather than hoping they each get it
> > right?
> >
> > I don't know what is involved here, so this is theoretical.
> > But I believe that compatibility should only be broken if necessary.
> > Also that fixing a problem at source is usually a lot cheaper than
> > requiring downstream developers/users to do so.
> > There are lots more of them, so any extra effort they have to expend
> > is multiplied many times.
> > In other words, the cost-benefit should not just look at the immediate
> > cost to the project.
> >
> >> +1 to 'go big or go home'. Break it now. Break it obviously.
> >
> > But I agree that breakage - if decided on - should be obvious.
> >
> >>
> >> 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?
>

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

[Ian Clelland]

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 the other updates to the plugin.

I'm committing changes to the plugin now to support this; the actual "set
the default so things don't break" code is isolated to a single commit, so
that it's super easy to revert or change later if we decide we don't like
it.

I've asked around here, nobody on the Google team has any objections to
this path.

Anis, you were also agreeing with me previously about breaking sooner
rather than later: Are you okay now with separating the two issues, just
doing the API upgrade now, and starting the process of promoting the new
locations before we change the default sometime in the next 12 months?



On Wed, Feb 5, 2014 at 11:19 AM, Joe Bowser  wrote:

> 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:
> >>
> >> > 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 two huge
> >> changes going on at the same time, and we will have to deal with a lot
> of
> >> heat for bugs *as well* as the location change.
> >>
> >>
> >> >  Lets let a subset of users upgrade to the new
> >> > $MAJOR version, and a subset of those add the new preference.  In a
> later
> >> > release, we can make the switch -- by then, maybe we will have more
> >> > solutions for migrating.
> >> >
> >> > Also, this is a nice to have, but its obviously been a situation that
> >> devs
> >> > have been living with for years.
> >> >
> >>
> >> That is something that I was thinking about last night. If we go with
> #3;
> >> put in a safe default, then we could spend a year if we wanted to
> promoting
> >> hard the "please please please switch to the better version" position.
> >>
> >> Then we could announce long in advance that we're changing the default,
> or
> >> that we're removing the default, and when we're ready, bump the major
> again
> >> to 2.x and do it.
> >>
> >> This might be the best situation for the developers, and it's no worse
> for
> >> the users than the situation right now. It's less than optimal for the
> >> "cordova ecosystem", but the ecosystem may be harmed more by angry
> >> developers leaving the platform than by continuing to place files where
> >> they are now.
> >>
> >>
> >> So this proposal would be:
> >>  - Don't revert the changes made on dev
> >>  - Don't rename the plugin
> >>  - Add a default which places files exactly where they are now
> >>  - Bump the major version
> >>  - Start fixing bugs in the new code. (without being distracted by the
> >> storage location change)
> >>  - Start blogging about the issue with storage locations, and encourage
> >> people to change (but don't force them to do anything yet)
> >>  - In a year, or when we feel that a sufficient mass of developers have
> >> gotten the message, broadcast that we're removing the default. (or
> changing
> >> it, if we're very confident in our plugin upgrade paths)
> >>  - Some months after that, make the change. (and hopefully not be
> >> distracted by bugs in the underlying plugin code) Bump the major version
> >> again.
> >>
> >> I'm actually pretty happy with that; we think that the current situation
> >> isn't great, but it doesn't seem to be actively hurting the ecosystem.
> And
> >> any developers who think otherwise will now have the tools to fix it for
> >> their own apps.
> >> Eventually we can be more opinionated about it, and the plugin will be
> more
> >> robust, so devs shouldn't be *as* angry as if we switched it right now.
> >>
> >> Ian
> >>
> >>
> >> > -Michal
> >> >
> >> >
> >> > On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
> >> >
> >> > > 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 knows what to migrate - we don't.\
> >> > >
> >> > > The app must tell the library what file names are involved.
> >> > > So unless the same API is used for files that are supposed to remain
> >> > > in the root, it should be possible to know what needs to move.
> >> > >
> >> > > It  may still prove too difficult to implement the merge, but
>

Re: [Android] SecureToken/NoFrak feature addition

[Joe Bowser]

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 the domain of the  tag as
> the only one the native side will provide a token to. Both Android and iOS
> can know the URL of the main frame, and choose not to provide a token if
> the domain doesn't match that of content (with file:/// always being
> allowed).
>
> Alternatively, we could block navigations of the top-level frame to other
> domains.
>
> wdyt?

Sounds good.  Can you do a PoC of this?

>
>
> On Fri, Jan 31, 2014 at 4:43 PM, Andrew Grieve  wrote:
>
>>
>>
>>
>> On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev wrote:
>>
>>> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve 
>>> wrote:
>>> > Why is loadUrl insecure? (hopefully something less horrible than
>>> > addJsInterface pre JB... :P)
>>>
>>> Think about the usecase where a benign website is framed by a
>>> malicious one. Again, this is server side. The app developer can't
>>> prevent it from happening. The framework developer must make sure that
>>> all usecases are handled properly.
>>>
>>
>>
>> Ah, I hadn't considered that the main frame might be malicious.
>>
>> I don't see how this would happen with a Cordova app though. We strongly
>> encourage users to use file:/// URLs for their app. For those that use
>> HTTP, that's insecure anyways and would be whitelisted by this scheme. If
>> you use HTTPS, then you should be fine, no?
>>

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

[Michal Mocny]

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 should have been run before the
*tooling release* (and even better, on a regular basis with CI as stated),
not necessarily before every patch to tip of tree lands.  The majority of
changes do not affect specific platforms in subtle ways -- and while we
should absolutely have process to catch those that do -- any process that
involves manually testing in multiple configurations for every single patch
is prohibitive and I think unrealistic.

That change was committed a month ago -- how did we not catch it before
release?

To decrease the odds of this happening again, perhaps we need to amend the
steps for tooling release (
http://wiki.apache.org/cordova/StepsForToolsRelease) to ensure testing on
all the platforms?

-Michal


On Wed, Feb 5, 2014 at 2:34 PM, Jesse  wrote:

> 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
> windows devices.
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Feb 5, 2014 at 11:22 AM, Mark Koudritsky 
> wrote:
>
> > Some CI for plugman and CLI on Windows would be extremely useful. I just
> > looked briefly at Travis-CI<
> > http://docs.travis-ci.com/user/getting-started/>,
> > but they only have Linux and OS
> > X.
> > Here is a random Windows based service I just found
> > http://www.appveyor.com/,
> > didn't check if it's usable for our case. Of course, this solution would
> > only be for the host side tools, not for on-device tests which are the
> most
> > important ones.
> >
> > That commit was part of this review
> >  dealing
> > with CB-4153 . But since
> > the
> > patch (probably prepared with git format-patch) contained two separate
> > commits and the second one didn't have a reference to the bug, there is
> no
> > way to deduce that reference. The lesson for me is to add CB-: prefix
> > to each commit message in a series of related commits. The check was
> added
> > to verity that config.xml does look like it's a Cordova related
> > config.xlmbecause with the new --link-to tag a random file named
> > config.xml by chance could be sitting in that www dir.
> >
> >
> > On Wed, Feb 5, 2014 at 2:14 PM, Steven Gill 
> > wrote:
> >
> > > 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?
> > >
> > >
> > > On Wed, Feb 5, 2014 at 10:41 AM, Parashuram Narasimhan (MS OPEN TECH) <
> > > panar...@microsoft.com> wrote:
> > >
> > > > 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 Windows8 users are currently unable to create new projects
> > > > WP8+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
> > > > 3.4.0 ships this will continue to break.
> > > >
> > > > I am unhappy about how this landed without discussion, or an issue in
> > > > jira, but ultimately this is just a symptom of the fact that not
> enough
> > > > people test on WP7+8 and Windows 8.
> > > > Please try to test all platforms before landing changes to
> cordova-cli,
> > > > cordova-plugman and cordova-js or at least tread lightly and try to
> > aware
> > > > of the impact outside of your pet platforms.  I am always available
> to
> > > > discuss possible impacts.
> > > >
> > > > Cheers,
> > > >   Jesse
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-cli/commit/837e8e367ae4feed4854f9ac95a8e906c893d818
> > > >
> > > > [2] https://issues.apache.org/jira/browse/CB-5957
> > > >
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > >
> >
>

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

[Jesse]

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
windows devices.

@purplecabbage
risingj.com


On Wed, Feb 5, 2014 at 11:22 AM, Mark Koudritsky  wrote:

> Some CI for plugman and CLI on Windows would be extremely useful. I just
> looked briefly at Travis-CI<
> http://docs.travis-ci.com/user/getting-started/>,
> but they only have Linux and OS
> X.
> Here is a random Windows based service I just found
> http://www.appveyor.com/,
> didn't check if it's usable for our case. Of course, this solution would
> only be for the host side tools, not for on-device tests which are the most
> important ones.
>
> That commit was part of this review
>  dealing
> with CB-4153 . But since
> the
> patch (probably prepared with git format-patch) contained two separate
> commits and the second one didn't have a reference to the bug, there is no
> way to deduce that reference. The lesson for me is to add CB-: prefix
> to each commit message in a series of related commits. The check was added
> to verity that config.xml does look like it's a Cordova related
> config.xlmbecause with the new --link-to tag a random file named
> config.xml by chance could be sitting in that www dir.
>
>
> On Wed, Feb 5, 2014 at 2:14 PM, Steven Gill 
> wrote:
>
> > 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?
> >
> >
> > On Wed, Feb 5, 2014 at 10:41 AM, Parashuram Narasimhan (MS OPEN TECH) <
> > panar...@microsoft.com> wrote:
> >
> > > 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 Windows8 users are currently unable to create new projects
> > > WP8+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
> > > 3.4.0 ships this will continue to break.
> > >
> > > I am unhappy about how this landed without discussion, or an issue in
> > > jira, but ultimately this is just a symptom of the fact that not enough
> > > people test on WP7+8 and Windows 8.
> > > Please try to test all platforms before landing changes to cordova-cli,
> > > cordova-plugman and cordova-js or at least tread lightly and try to
> aware
> > > of the impact outside of your pet platforms.  I am always available to
> > > discuss possible impacts.
> > >
> > > Cheers,
> > >   Jesse
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/apache/cordova-cli/commit/837e8e367ae4feed4854f9ac95a8e906c893d818
> > >
> > > [2] https://issues.apache.org/jira/browse/CB-5957
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> >
>

Re: [Android] Deprecation of Geolocation on Android

[Joe Bowser]

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 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 Web GPS on 2.3 (lowest that we have) and it worked
>> fine.
>>
>>
>> On Mon, Jan 13, 2014 at 1:54 PM, Joe Bowser  wrote:
>>>
>>> So, an update on this.
>>>
>>> 1. Our users don't know how GPS works! I can reproduce Geolocation
>>> errors only by disconnecting my WiFi and by not having a SIM in the
>>> phone and expecting my GPS to magically get the signal from inside my
>>> office (It takes 2 minutes at least).  I can't change the laws of
>>> physics, so this is working as intended
>>> 2. Our GPS doesn't work any better or worse than Web GPS
>>> 3. We'll still have people filing bugs against the Geolocation plugin
>>> that I can't reproduce, I'd rather close them as Web GPS problems than
>>> "You've never used GPS before, I can't reproduce" problems.
>>>
>>> I think we should deprecate the code for the time being, since there
>>> isn't actually anything wrong with it other than the fact that it has
>>> a 60s callback (which was considered reasonable in the old days of
>>> 2008 when batteries died more quickly).
>>>
>>> On Sat, Jan 11, 2014 at 12:33 PM, Lindsey Simon 
>>> wrote:
>>> > +1 to nuking it.
>>> >
>>> > Anyone depending on it for really old versions of Android is likely not
>>> > doing anyone a favor (themselves or their users) - and (I think) it
>>> > adds to
>>> > new developer confusion. Then again, having a plugin that only adds the
>>> > permission bit sort of does that too.
>>> >
>>> >
>>> >
>>> > On Fri, Jan 10, 2014 at 7:26 PM, Michal Mocny 
>>> > wrote:
>>> >>
>>> >> Adding support for play services based geolocation could come as a
>>> >> value
>>> >> add later.  If the current implementation is broken and no one wants
>>> >> to
>>> >> work on it (seems to be the case since it hasn't been fixed yet), then
>>> >> Joe's suggestion to just drop it now and leave a no-op plugin that
>>> >> adds
>>> >> permission only sounds like the right thing short term.
>>> >>
>>> >> Joes first email claims Web Geolocation supports all current versions
>>> >> of
>>> >> android (http://caniuse.com/geolocation claims android 2.1+ though I
>>> >> didn't
>>> >> look in to possible quirks).
>>> >>
>>> >> -Michal
>>> >>
>>> >>
>>> >> On Fri, Jan 10, 2014 at 8:43 PM, Andrew Grieve 
>>> >> wrote:
>>> >>
>>> >> > Is the plugin still needed on older android versions? e.g. we might
>>> >> > want to have it be a no-op based on the android version instead of
>>> >> > deleting it?
>>> >> >
>>> >> > Android geolocation seems to have gone Play Services, so another
>>> >> > option would be to make the plugin use that instead of the OS
>>> >> > geolocation in order to provide some utility.
>>> >> >
>>> >> > On Fri, Jan 10, 2014 at 4:14 PM, Jesse 
>>> >> > wrote:
>>> >> > > The index.html issue was iOS, not sure if it still exists.
>>> >> > >
>>> >> > > Windows Phone 7+8 use the browser based geolocation as they have
>>> >> > > implemented the spec,  However because of the way permissions are
>>> >> > managed,
>>> >> > > there is a native do-nothing stub that simply signal that Location
>>> >> > Services
>>> >> > > are required.
>>> >> > > Windows8 does some massaging of the api to the WinJS version, and
>>> >> > > adds
>>> >> > the
>>> >> > > permissions to the project.
>>> >> > >
>>> >> > > I just spoke ( physically ) with Joe, and with this change, the
>>> >> > geolocation
>>> >> > > plugin would still exist for Android, it would just add the
>>> >> > > permission
>>> >> > > to
>>> >> > > the app.  So, Android's plugin would be almost identical to WP7+8
>>> >> > > with
>>> >> > this
>>> >> > > change.
>>> >> > >
>>> >> > > +1 from me, assuming everything will just work.
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > @purplecabbage
>>> >> > > risingj.com
>>> >> > >
>>> >> > >
>>> >> > > On Fri, Jan 10, 2014 at 3:40 PM, Joe Bowser 
>>> >> > > wrote:
>>> >> > >
>>> >> > >> It never did on Android, you can see this in Mobile-Spec.
>>> >> > >>
>>> >> > >> On Fri, Jan 10, 2014 at 3:39 PM, Brian LeRoux  wrote:
>>> >> > >> > Does the permission dialogue still ask for index.html ?
>>> >> > >> >
>>> >> > >> >
>>> >> > >> > On Friday, January 10, 2014, Joe Bowser wrote:
>>> >> > >> >>
>>> >> > >> >> Due to numerous issues found in Geolocation, combined with an
>>> >> > increase
>>> >> > >> >> in reliability of the Web Geolocation, I'm wanting to see us
>>> >> > >> >> EOL
>>> >> > >> >> the
>>> >> > >> >> Geolocation plugin.
>>> >> > >> >>
>>> >> > >> >> Reasons for this include:
>>> >> > >> >>  * Support for Geolocation on all currently supported versions
>>> >>

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

[Mark Koudritsky]

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://www.appveyor.com/,
didn't check if it's usable for our case. Of course, this solution would
only be for the host side tools, not for on-device tests which are the most
important ones.

That commit was part of this review
 dealing
with CB-4153 . But since the
patch (probably prepared with git format-patch) contained two separate
commits and the second one didn't have a reference to the bug, there is no
way to deduce that reference. The lesson for me is to add CB-: prefix
to each commit message in a series of related commits. The check was added
to verity that config.xml does look like it's a Cordova related
config.xlmbecause with the new --link-to tag a random file named
config.xml by chance could be sitting in that www dir.


On Wed, Feb 5, 2014 at 2:14 PM, Steven Gill  wrote:

> 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?
>
>
> On Wed, Feb 5, 2014 at 10:41 AM, Parashuram Narasimhan (MS OPEN TECH) <
> panar...@microsoft.com> wrote:
>
> > 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 Windows8 users are currently unable to create new projects
> > WP8+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
> > 3.4.0 ships this will continue to break.
> >
> > I am unhappy about how this landed without discussion, or an issue in
> > jira, but ultimately this is just a symptom of the fact that not enough
> > people test on WP7+8 and Windows 8.
> > Please try to test all platforms before landing changes to cordova-cli,
> > cordova-plugman and cordova-js or at least tread lightly and try to aware
> > of the impact outside of your pet platforms.  I am always available to
> > discuss possible impacts.
> >
> > Cheers,
> >   Jesse
> >
> > [1]
> >
> >
> https://github.com/apache/cordova-cli/commit/837e8e367ae4feed4854f9ac95a8e906c893d818
> >
> > [2] https://issues.apache.org/jira/browse/CB-5957
> >
> >
> > @purplecabbage
> > risingj.com
> >
>

Re: [Android] Deprecation of Geolocation on Android

[Mike Billau]

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 Web GPS on 2.3 (lowest that we have) and it worked
> fine.
>
>
> On Mon, Jan 13, 2014 at 1:54 PM, Joe Bowser  wrote:
>
>> So, an update on this.
>>
>> 1. Our users don't know how GPS works! I can reproduce Geolocation
>> errors only by disconnecting my WiFi and by not having a SIM in the
>> phone and expecting my GPS to magically get the signal from inside my
>> office (It takes 2 minutes at least).  I can't change the laws of
>> physics, so this is working as intended
>> 2. Our GPS doesn't work any better or worse than Web GPS
>> 3. We'll still have people filing bugs against the Geolocation plugin
>> that I can't reproduce, I'd rather close them as Web GPS problems than
>> "You've never used GPS before, I can't reproduce" problems.
>>
>> I think we should deprecate the code for the time being, since there
>> isn't actually anything wrong with it other than the fact that it has
>> a 60s callback (which was considered reasonable in the old days of
>> 2008 when batteries died more quickly).
>>
>> On Sat, Jan 11, 2014 at 12:33 PM, Lindsey Simon 
>> wrote:
>> > +1 to nuking it.
>> >
>> > Anyone depending on it for really old versions of Android is likely not
>> > doing anyone a favor (themselves or their users) - and (I think) it
>> adds to
>> > new developer confusion. Then again, having a plugin that only adds the
>> > permission bit sort of does that too.
>> >
>> >
>> >
>> > On Fri, Jan 10, 2014 at 7:26 PM, Michal Mocny 
>> wrote:
>> >>
>> >> Adding support for play services based geolocation could come as a
>> value
>> >> add later.  If the current implementation is broken and no one wants to
>> >> work on it (seems to be the case since it hasn't been fixed yet), then
>> >> Joe's suggestion to just drop it now and leave a no-op plugin that adds
>> >> permission only sounds like the right thing short term.
>> >>
>> >> Joes first email claims Web Geolocation supports all current versions
>> of
>> >> android (http://caniuse.com/geolocation claims android 2.1+ though I
>> >> didn't
>> >> look in to possible quirks).
>> >>
>> >> -Michal
>> >>
>> >>
>> >> On Fri, Jan 10, 2014 at 8:43 PM, Andrew Grieve 
>> >> wrote:
>> >>
>> >> > Is the plugin still needed on older android versions? e.g. we might
>> >> > want to have it be a no-op based on the android version instead of
>> >> > deleting it?
>> >> >
>> >> > Android geolocation seems to have gone Play Services, so another
>> >> > option would be to make the plugin use that instead of the OS
>> >> > geolocation in order to provide some utility.
>> >> >
>> >> > On Fri, Jan 10, 2014 at 4:14 PM, Jesse 
>> wrote:
>> >> > > The index.html issue was iOS, not sure if it still exists.
>> >> > >
>> >> > > Windows Phone 7+8 use the browser based geolocation as they have
>> >> > > implemented the spec,  However because of the way permissions are
>> >> > managed,
>> >> > > there is a native do-nothing stub that simply signal that Location
>> >> > Services
>> >> > > are required.
>> >> > > Windows8 does some massaging of the api to the WinJS version, and
>> adds
>> >> > the
>> >> > > permissions to the project.
>> >> > >
>> >> > > I just spoke ( physically ) with Joe, and with this change, the
>> >> > geolocation
>> >> > > plugin would still exist for Android, it would just add the
>> permission
>> >> > > to
>> >> > > the app.  So, Android's plugin would be almost identical to WP7+8
>> with
>> >> > this
>> >> > > change.
>> >> > >
>> >> > > +1 from me, assuming everything will just work.
>> >> > >
>> >> > >
>> >> > >
>> >> > > @purplecabbage
>> >> > > risingj.com
>> >> > >
>> >> > >
>> >> > > On Fri, Jan 10, 2014 at 3:40 PM, Joe Bowser 
>> wrote:
>> >> > >
>> >> > >> It never did on Android, you can see this in Mobile-Spec.
>> >> > >>
>> >> > >> On Fri, Jan 10, 2014 at 3:39 PM, Brian LeRoux  wrote:
>> >> > >> > Does the permission dialogue still ask for index.html ?
>> >> > >> >
>> >> > >> >
>> >> > >> > On Friday, January 10, 2014, Joe Bowser wrote:
>> >> > >> >>
>> >> > >> >> Due to numerous issues found in Geolocation, combined with an
>> >> > increase
>> >> > >> >> in reliability of the Web Geolocation, I'm wanting to see us
>> EOL
>> >> > >> >> the
>> >> > >> >> Geolocation plugin.
>> >> > >> >>
>> >> > >> >> Reasons for this include:
>> >> > >> >>  * Support for Geolocation on all currently supported versions
>> of
>> >> > >> Android
>> >> > >> >>  * Numerous issues with the current Geolocation plugin that may
>> >> > >> >> involve a full re-write of the Geolocation plugins.
>> >> > >> >>  * The Web Geolocation may be more energy efficient than our
>> own
>> >> > >> >> Geolocation polling.
>> >> > >> >>
>> >> > >> >> What do people think about deprecating this plugin and
>> >> > 

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

[Steven Gill]

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?


On Wed, Feb 5, 2014 at 10:41 AM, Parashuram Narasimhan (MS OPEN TECH) <
panar...@microsoft.com> wrote:

> 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 Windows8 users are currently unable to create new projects
> WP8+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
> 3.4.0 ships this will continue to break.
>
> I am unhappy about how this landed without discussion, or an issue in
> jira, but ultimately this is just a symptom of the fact that not enough
> people test on WP7+8 and Windows 8.
> Please try to test all platforms before landing changes to cordova-cli,
> cordova-plugman and cordova-js or at least tread lightly and try to aware
> of the impact outside of your pet platforms.  I am always available to
> discuss possible impacts.
>
> Cheers,
>   Jesse
>
> [1]
>
> https://github.com/apache/cordova-cli/commit/837e8e367ae4feed4854f9ac95a8e906c893d818
>
> [2] https://issues.apache.org/jira/browse/CB-5957
>
>
> @purplecabbage
> risingj.com
>

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

[Parashuram Narasimhan (MS OPEN TECH)]

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 Windows8 users are currently unable to create new projects 
WP8+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
3.4.0 ships this will continue to break.

I am unhappy about how this landed without discussion, or an issue in jira, but 
ultimately this is just a symptom of the fact that not enough people test on 
WP7+8 and Windows 8.
Please try to test all platforms before landing changes to cordova-cli, 
cordova-plugman and cordova-js or at least tread lightly and try to aware of 
the impact outside of your pet platforms.  I am always available to discuss 
possible impacts.

Cheers,
  Jesse

[1]
https://github.com/apache/cordova-cli/commit/837e8e367ae4feed4854f9ac95a8e906c893d818

[2] https://issues.apache.org/jira/browse/CB-5957


@purplecabbage
risingj.com

Re: input type=file broken on Android 4.4

[Mike Billau]

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 in the WebView because:
1. We don't want to build a file picker UI and have to maintain that
2. The bug seems fixed in Chrome Beta so hopefully the fix will make it
into the WebView soon
3. There are probably a few different ways people can handle this with
File/FileTransfer and the solution might be different for everyone

One secondary issue is: Where to add this documentation? There isn't an
overall "Android Platform Quirks" section, so we could either add this as
an additional guide under Android, or add it in the Android Upgrade Guide
[1], or just a blog post. Personally I think adding a new guide is too much
overhead and would perfer to stick the notice in the Upgrade Guide by the
first version of Cordova that supported 4.4. If nobody has any objections,
I'll add a quirk note to the Upgrading Guide, section "Updating to 3.2 from
3.1"

Here is the text I want to use:
"Starting on Android 4.4, creating a file input element with type="file"
will not open the file picker dialog.
This is a regression with Chromium on Android and the problem can be
reproduced in the standalone Chrome browser on Android (see
http://code.google.com/p/android/issues/detail?id=62220)  The suggested
workaround is to use the FileTransfer and File plugins for Android 4.4. You
can listen for an onClick event from the input type="file" and then pop up
a file picker UI. In order to tie the form data with the upload, you can
use JavaScript to attach form values to the multi-part POST request that
FileTransfer makes."


[1]
http://cordova.apache.org/docs/en/edge/guide_platforms_android_upgrading.md.html#Upgrading%20Android






On Fri, Nov 15, 2013 at 11:34 PM, James Jong  wrote:

> Ugh... hopefully there's a better solution.
> -James Jong
>
> On Nov 14, 2013, at 2:10 PM, Brian LeRoux  wrote:
>
> > Ugly indeed but that is what we do! =)
> >
> > Probably just a docs issue doing what you describe.
> >
> >
> > On Thu, Nov 14, 2013 at 10:57 AM, Andrew Grieve  >wrote:
> >
> >> I'll ask around and see if anyone has ideas on fixing it.
> >>
> >> We could probably polyfill it though, by having a click handler on the
> body
> >> looking for clicks on , and then hijacking the
> onsubmit()
> >> of the form. Ugly.
> >>
> >>
> >> On Thu, Nov 14, 2013 at 12:09 PM, Brian LeRoux  wrote:
> >>
> >>> I think it is reasonable that we choose to allow a polyfill for this
> >>> regardless of the Google stance. The change is very likely to break
> >>> existing users and just b/c it was 'private' doesn't mean that it
> wasn't
> >>> exposed. Maybe this is just a docs issue given we have the scaffolding
> to
> >>> fix this with File/FileTransfer.
> >>>
> >>> ??
> >>>
> >>>
> >>> On Thu, Nov 14, 2013 at 8:39 AM, Joe Bowser  wrote:
> >>>
>  Apologize and say "Sorry, the Android team hates Cordova"?
> 
>  Honestly, was this a private API that was in the Android Browser code?
>  If so, then we should assume that this would break, since this wasn't
>  referenced in the Android APIs.  This is outside our scope, and we
>  really can't do anything more with this without even more breakage.
> 
>  On Thu, Nov 14, 2013 at 8:26 AM, Mike Billau 
>  wrote:
> > Hi everyone,
> >
> > This ticket[1] came in pretty recently talking about how input
> >>> type=file
> > does not work with Android 4.4 anymore, regardless of what your
> >> target
>  SDK
> > is.
> >
> > Apparently this was a conscious design decision by Android [2].
> >
> > Does anybody have ideas on how we can fix this? Is this even in our
>  scope?
> > From what I can gather, we have always had to override certain
> >> 'hidden'
> > (yet public) methods on CordovaChromeClient [3] to enable input
>  type=file.
> > I'm thinking that either Android made this a private method or they
> >>> just
> > changed the method signature again. If they just changed the method
> > signature, hopefully the new one will surface pretty soon and we can
>  adjust
> > CordovaChromeClient (I tried looking around in Android source but got
> > pretty lost pretty quick...)
> >
> > Just wanted to get some more opinions on what we should do. This
> >> seems
>  like
> > it could be a pretty breaking change for some of our users.
> >
> >
> > [1] https://issues.apache.org/jira/browse/CB-5294
> > [2] http://code.google.com/p/android/issues/detail?id=62220
> > [3]
> >
> 
> >>>
> >>
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaChromeClient.java#L367
> 
> >>>
> >>
>
>

Need to revert a CLI breaking change causing CB-5957

[Jesse]

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
3.4.0 ships this will continue to break.

I am unhappy about how this landed without discussion, or an issue in jira,
but ultimately this is just a symptom of the fact that not enough people
test on WP7+8 and Windows 8.
Please try to test all platforms before landing changes to cordova-cli,
cordova-plugman and cordova-js or at least tread lightly and try to aware
of the impact outside of your pet platforms.  I am always available to
discuss possible impacts.

Cheers,
  Jesse

[1]
https://github.com/apache/cordova-cli/commit/837e8e367ae4feed4854f9ac95a8e906c893d818

[2] https://issues.apache.org/jira/browse/CB-5957


@purplecabbage
risingj.com

Re: Get Mac address from iPhone and Android

[Shazron]

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-of-access-point-in-ios
> >will
> 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 iOS you can't. Or more specifically you can but Apple has
> changed
> > the API function  to return a constant value for all devices.
> >
> > On Thursday, January 30, 2014, Gustavo Azambuja 
> > wrote:
> >
> > > Hi, I need to get the mac address (not for UID, I realy need only the
> mac
> > > address of wifi).
> > > How I can get this? some plugin?
> > >
> > > Thanks!
> > >
> > > --
> > > Gustavo Azambuja
> > > http://gazambuja.com
> > > 
> > > Uruguay: *091 300 333* (Montevideo - Mobile)
> > >
> >
>

Re: Get Mac address from iPhone and Android

[Zach W]

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 iOS you can't. Or more specifically you can but Apple has changed
> the API function  to return a constant value for all devices.
>
> On Thursday, January 30, 2014, Gustavo Azambuja 
> wrote:
>
> > Hi, I need to get the mac address (not for UID, I realy need only the mac
> > address of wifi).
> > How I can get this? some plugin?
> >
> > Thanks!
> >
> > --
> > Gustavo Azambuja
> > http://gazambuja.com
> > 
> > Uruguay: *091 300 333* (Montevideo - Mobile)
> >
>

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

[Joe Bowser]

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:
>>
>> > 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 two huge
>> changes going on at the same time, and we will have to deal with a lot of
>> heat for bugs *as well* as the location change.
>>
>>
>> >  Lets let a subset of users upgrade to the new
>> > $MAJOR version, and a subset of those add the new preference.  In a later
>> > release, we can make the switch -- by then, maybe we will have more
>> > solutions for migrating.
>> >
>> > Also, this is a nice to have, but its obviously been a situation that
>> devs
>> > have been living with for years.
>> >
>>
>> That is something that I was thinking about last night. If we go with #3;
>> put in a safe default, then we could spend a year if we wanted to promoting
>> hard the "please please please switch to the better version" position.
>>
>> Then we could announce long in advance that we're changing the default, or
>> that we're removing the default, and when we're ready, bump the major again
>> to 2.x and do it.
>>
>> This might be the best situation for the developers, and it's no worse for
>> the users than the situation right now. It's less than optimal for the
>> "cordova ecosystem", but the ecosystem may be harmed more by angry
>> developers leaving the platform than by continuing to place files where
>> they are now.
>>
>>
>> So this proposal would be:
>>  - Don't revert the changes made on dev
>>  - Don't rename the plugin
>>  - Add a default which places files exactly where they are now
>>  - Bump the major version
>>  - Start fixing bugs in the new code. (without being distracted by the
>> storage location change)
>>  - Start blogging about the issue with storage locations, and encourage
>> people to change (but don't force them to do anything yet)
>>  - In a year, or when we feel that a sufficient mass of developers have
>> gotten the message, broadcast that we're removing the default. (or changing
>> it, if we're very confident in our plugin upgrade paths)
>>  - Some months after that, make the change. (and hopefully not be
>> distracted by bugs in the underlying plugin code) Bump the major version
>> again.
>>
>> I'm actually pretty happy with that; we think that the current situation
>> isn't great, but it doesn't seem to be actively hurting the ecosystem. And
>> any developers who think otherwise will now have the tools to fix it for
>> their own apps.
>> Eventually we can be more opinionated about it, and the plugin will be more
>> robust, so devs shouldn't be *as* angry as if we switched it right now.
>>
>> Ian
>>
>>
>> > -Michal
>> >
>> >
>> > On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
>> >
>> > > 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 knows what to migrate - we don't.\
>> > >
>> > > The app must tell the library what file names are involved.
>> > > So unless the same API is used for files that are supposed to remain
>> > > in the root, it should be possible to know what needs to move.
>> > >
>> > > It  may still prove too difficult to implement the merge, but perhaps
>> > > there is some scope for adding something to help the developers.
>> > >
>> > > For example, the code could check if there is a file with the same
>> > > name in the old location, and log a message if so.
>> > > There may be other checks that would help mitigate the breakage.
>> > >
>> > > >
>> > > > On Wed, Feb 5, 2014 at 9: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 implement
>> > > >> something similar in order to make it easier for their users.
>> > > >>
>> > > >> Would it not be better to spend the time getting it right once, for
>> > > >> the benfit of all developers, rather than hoping they each get it
>> > > >> right?
>> > > >>
>> > > >> I don't know what is involved here, so this is theoretical.
>> > > >> But I believe that compatibility should only be broken if necessary.
>> > > >> Also that fixing a problem at source is usually a lot cheaper than
>> > > >> requiring downstream developers/users to do so.
>> > > >> There are lots more of them, so any ext

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

[Tommy Williams]

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 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 two huge
> changes going on at the same time, and we will have to deal with a lot of
> heat for bugs *as well* as the location change.
>
>
> >  Lets let a subset of users upgrade to the new
> > $MAJOR version, and a subset of those add the new preference.  In a later
> > release, we can make the switch -- by then, maybe we will have more
> > solutions for migrating.
> >
> > Also, this is a nice to have, but its obviously been a situation that
> devs
> > have been living with for years.
> >
>
> That is something that I was thinking about last night. If we go with #3;
> put in a safe default, then we could spend a year if we wanted to promoting
> hard the "please please please switch to the better version" position.
>
> Then we could announce long in advance that we're changing the default, or
> that we're removing the default, and when we're ready, bump the major again
> to 2.x and do it.
>
> This might be the best situation for the developers, and it's no worse for
> the users than the situation right now. It's less than optimal for the
> "cordova ecosystem", but the ecosystem may be harmed more by angry
> developers leaving the platform than by continuing to place files where
> they are now.
>
>
> So this proposal would be:
>  - Don't revert the changes made on dev
>  - Don't rename the plugin
>  - Add a default which places files exactly where they are now
>  - Bump the major version
>  - Start fixing bugs in the new code. (without being distracted by the
> storage location change)
>  - Start blogging about the issue with storage locations, and encourage
> people to change (but don't force them to do anything yet)
>  - In a year, or when we feel that a sufficient mass of developers have
> gotten the message, broadcast that we're removing the default. (or changing
> it, if we're very confident in our plugin upgrade paths)
>  - Some months after that, make the change. (and hopefully not be
> distracted by bugs in the underlying plugin code) Bump the major version
> again.
>
> I'm actually pretty happy with that; we think that the current situation
> isn't great, but it doesn't seem to be actively hurting the ecosystem. And
> any developers who think otherwise will now have the tools to fix it for
> their own apps.
> Eventually we can be more opinionated about it, and the plugin will be more
> robust, so devs shouldn't be *as* angry as if we switched it right now.
>
> Ian
>
>
> > -Michal
> >
> >
> > On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
> >
> > > 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 knows what to migrate - we don't.\
> > >
> > > The app must tell the library what file names are involved.
> > > So unless the same API is used for files that are supposed to remain
> > > in the root, it should be possible to know what needs to move.
> > >
> > > It  may still prove too difficult to implement the merge, but perhaps
> > > there is some scope for adding something to help the developers.
> > >
> > > For example, the code could check if there is a file with the same
> > > name in the old location, and log a message if so.
> > > There may be other checks that would help mitigate the breakage.
> > >
> > > >
> > > > On Wed, Feb 5, 2014 at 9: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 implement
> > > >> something similar in order to make it easier for their users.
> > > >>
> > > >> Would it not be better to spend the time getting it right once, for
> > > >> the benfit of all developers, rather than hoping they each get it
> > > >> right?
> > > >>
> > > >> I don't know what is involved here, so this is theoretical.
> > > >> But I believe that compatibility should only be broken if necessary.
> > > >> Also that fixing a problem at source is usually a lot cheaper than
> > > >> requiring downstream developers/users to do so.
> > > >> There are lots more of them, so any extra effort they have to expend
> > > >> is multiplied many times.
> > > >> In other words, the cost-benefit should not just look at the
> immediate
> > > >> cost to the project.
> > > >>
> > > >> > +1 to 'go big or go 

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

[Joe Bowser]

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)
> maintaining an app built using Cordova is actually pretty painful
> sometimes... Even for me, and I am on this list and see this stuff coming.
>
> If you think the new way is the best one true way, then leave the default
> as is and *educate* people as to why. The File API is one of the *most*
> used plugins of the core plugins. Breaking that big a percentage of
> existing apps  at 3.4 seems unwise to me.
>
> I know, I know... The plugins are separately versioned and this will be a
> major version change.. Tell me, has any dev had to know or really even been
> exposed to the fact that the plugins have their own versions yet? It's not
> like we have a package.json file with deps in it all semvered based on
> "last known good" versions like a node app might. I doubt many devs even
> know you *can* install a particular version of a plugin. If when installing
> a plugin we had --save-deps or something, and that used versions and kind
> of pinned the app to that major version, then a breaking version change
> might not break as many hearts ;)
>
> - tommy
> On 06/02/2014 2:26 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.  Lets let a subset of users upgrade to the new
>> $MAJOR version, and a subset of those add the new preference.  In a later
>> release, we can make the switch -- by then, maybe we will have more
>> solutions for migrating.
>>
>> Also, this is a nice to have, but its obviously been a situation that devs
>> have been living with for years.
>>
>> -Michal
>>
>>
>> On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
>>
>> > 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 knows what to migrate - we don't.\
>> >
>> > The app must tell the library what file names are involved.
>> > So unless the same API is used for files that are supposed to remain
>> > in the root, it should be possible to know what needs to move.
>> >
>> > It  may still prove too difficult to implement the merge, but perhaps
>> > there is some scope for adding something to help the developers.
>> >
>> > For example, the code could check if there is a file with the same
>> > name in the old location, and log a message if so.
>> > There may be other checks that would help mitigate the breakage.
>> >
>> > >
>> > > On Wed, Feb 5, 2014 at 9: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 implement
>> > >> something similar in order to make it easier for their users.
>> > >>
>> > >> Would it not be better to spend the time getting it right once, for
>> > >> the benfit of all developers, rather than hoping they each get it
>> > >> right?
>> > >>
>> > >> I don't know what is involved here, so this is theoretical.
>> > >> But I believe that compatibility should only be broken if necessary.
>> > >> Also that fixing a problem at source is usually a lot cheaper than
>> > >> requiring downstream developers/users to do so.
>> > >> There are lots more of them, so any extra effort they have to expend
>> > >> is multiplied many times.
>> > >> In other words, the cost-benefit should not just look at the immediate
>> > >> cost to the project.
>> > >>
>> > >> > +1 to 'go big or go home'. Break it now. Break it obviously.
>> > >>
>> > >> But I agree that breakage - if decided on - should be obvious.
>> > >>
>> > >> >
>> > >> > 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?
>> > >>
>> >
>>

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

[Joe Bowser]

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 implement
> something similar in order to make it easier for their users.
>
> Would it not be better to spend the time getting it right once, for
> the benfit of all developers, rather than hoping they each get it
> right?
>
> I don't know what is involved here, so this is theoretical.
> But I believe that compatibility should only be broken if necessary.
> Also that fixing a problem at source is usually a lot cheaper than
> requiring downstream developers/users to do so.
> There are lots more of them, so any extra effort they have to expend
> is multiplied many times.
> In other words, the cost-benefit should not just look at the immediate
> cost to the project.
>
>> +1 to 'go big or go home'. Break it now. Break it obviously.
>
> But I agree that breakage - if decided on - should be obvious.
>
>>
>> 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?

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

[Tommy Williams]

-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 coming.

If you think the new way is the best one true way, then leave the default
as is and *educate* people as to why. The File API is one of the *most*
used plugins of the core plugins. Breaking that big a percentage of
existing apps  at 3.4 seems unwise to me.

I know, I know... The plugins are separately versioned and this will be a
major version change.. Tell me, has any dev had to know or really even been
exposed to the fact that the plugins have their own versions yet? It's not
like we have a package.json file with deps in it all semvered based on
"last known good" versions like a node app might. I doubt many devs even
know you *can* install a particular version of a plugin. If when installing
a plugin we had --save-deps or something, and that used versions and kind
of pinned the app to that major version, then a breaking version change
might not break as many hearts ;)

- tommy
On 06/02/2014 2:26 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.  Lets let a subset of users upgrade to the new
> $MAJOR version, and a subset of those add the new preference.  In a later
> release, we can make the switch -- by then, maybe we will have more
> solutions for migrating.
>
> Also, this is a nice to have, but its obviously been a situation that devs
> have been living with for years.
>
> -Michal
>
>
> On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
>
> > 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 knows what to migrate - we don't.\
> >
> > The app must tell the library what file names are involved.
> > So unless the same API is used for files that are supposed to remain
> > in the root, it should be possible to know what needs to move.
> >
> > It  may still prove too difficult to implement the merge, but perhaps
> > there is some scope for adding something to help the developers.
> >
> > For example, the code could check if there is a file with the same
> > name in the old location, and log a message if so.
> > There may be other checks that would help mitigate the breakage.
> >
> > >
> > > On Wed, Feb 5, 2014 at 9: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 implement
> > >> something similar in order to make it easier for their users.
> > >>
> > >> Would it not be better to spend the time getting it right once, for
> > >> the benfit of all developers, rather than hoping they each get it
> > >> right?
> > >>
> > >> I don't know what is involved here, so this is theoretical.
> > >> But I believe that compatibility should only be broken if necessary.
> > >> Also that fixing a problem at source is usually a lot cheaper than
> > >> requiring downstream developers/users to do so.
> > >> There are lots more of them, so any extra effort they have to expend
> > >> is multiplied many times.
> > >> In other words, the cost-benefit should not just look at the immediate
> > >> cost to the project.
> > >>
> > >> > +1 to 'go big or go home'. Break it now. Break it obviously.
> > >>
> > >> But I agree that breakage - if decided on - should be obvious.
> > >>
> > >> >
> > >> > 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?
> > >>
> >
>

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

[Ian Clelland]

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 two huge
changes going on at the same time, and we will have to deal with a lot of
heat for bugs *as well* as the location change.


>  Lets let a subset of users upgrade to the new
> $MAJOR version, and a subset of those add the new preference.  In a later
> release, we can make the switch -- by then, maybe we will have more
> solutions for migrating.
>
> Also, this is a nice to have, but its obviously been a situation that devs
> have been living with for years.
>

That is something that I was thinking about last night. If we go with #3;
put in a safe default, then we could spend a year if we wanted to promoting
hard the "please please please switch to the better version" position.

Then we could announce long in advance that we're changing the default, or
that we're removing the default, and when we're ready, bump the major again
to 2.x and do it.

This might be the best situation for the developers, and it's no worse for
the users than the situation right now. It's less than optimal for the
"cordova ecosystem", but the ecosystem may be harmed more by angry
developers leaving the platform than by continuing to place files where
they are now.


So this proposal would be:
 - Don't revert the changes made on dev
 - Don't rename the plugin
 - Add a default which places files exactly where they are now
 - Bump the major version
 - Start fixing bugs in the new code. (without being distracted by the
storage location change)
 - Start blogging about the issue with storage locations, and encourage
people to change (but don't force them to do anything yet)
 - In a year, or when we feel that a sufficient mass of developers have
gotten the message, broadcast that we're removing the default. (or changing
it, if we're very confident in our plugin upgrade paths)
 - Some months after that, make the change. (and hopefully not be
distracted by bugs in the underlying plugin code) Bump the major version
again.

I'm actually pretty happy with that; we think that the current situation
isn't great, but it doesn't seem to be actively hurting the ecosystem. And
any developers who think otherwise will now have the tools to fix it for
their own apps.
Eventually we can be more opinionated about it, and the plugin will be more
robust, so devs shouldn't be *as* angry as if we switched it right now.

Ian


> -Michal
>
>
> On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:
>
> > 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 knows what to migrate - we don't.\
> >
> > The app must tell the library what file names are involved.
> > So unless the same API is used for files that are supposed to remain
> > in the root, it should be possible to know what needs to move.
> >
> > It  may still prove too difficult to implement the merge, but perhaps
> > there is some scope for adding something to help the developers.
> >
> > For example, the code could check if there is a file with the same
> > name in the old location, and log a message if so.
> > There may be other checks that would help mitigate the breakage.
> >
> > >
> > > On Wed, Feb 5, 2014 at 9: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 implement
> > >> something similar in order to make it easier for their users.
> > >>
> > >> Would it not be better to spend the time getting it right once, for
> > >> the benfit of all developers, rather than hoping they each get it
> > >> right?
> > >>
> > >> I don't know what is involved here, so this is theoretical.
> > >> But I believe that compatibility should only be broken if necessary.
> > >> Also that fixing a problem at source is usually a lot cheaper than
> > >> requiring downstream developers/users to do so.
> > >> There are lots more of them, so any extra effort they have to expend
> > >> is multiplied many times.
> > >> In other words, the cost-benefit should not just look at the immediate
> > >> cost to the project.
> > >>
> > >> > +1 to 'go big or go home'. Break it now. Break it obviously.
> > >>
> > >> But I agree that breakage - if decided on - should be obvious.
> > >>
> > >> >
> > >> > 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 comple

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

[Ian Clelland]

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 write any migration tools but document the changes in
> plugin.xml ( tag), write a blog post about it, tweet it, Google plus
> it and... Be super loud about it.
>
> It's not like we are breaking everything for everyone either. We have
> plugin versions for a reason.
>

Right, this was going to be the first test of a major version bump of a
published plugin. We want this to be a step that developers need to take
deliberately, I think.


>
> Another way of avoiding this would have been to pick a different name for
> this plugin. Is it too late?
>

Not too late; it would be some work to cherry-pick the unrelated fixes from
dev, but we could do it. Maybe we should do that anyway, and maintain an
0.x line for people who won't/cant' upgrade.

Ian

On Feb 5, 2014 7:03 AM, "Ian Clelland"  wrote:
>
> > 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
> > patterns. Reads and writes can happen anywhere in a file; we can't
> enforce
> > that a file is written out entirely in one call, so there may not be a
> > point where we can say "it's done; delete the old one".
> >
> > It's also entirely possible for multiple readers to be open on the file,
> > and for another thread to have a writer open, writing somewhere in the
> > middle of the file, so I would expect race conditions.
> >
> > This isn't *impossible*; there have been OS filesystems which do this
> for a
> > long time, but it seems to me to be a lot more work than writing a tool
> for
> > developers to use for migration, and much more error prone.
> >
>

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

[Anis KADRI]

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.xml ( tag), write a blog post about it, tweet it, Google plus
it and... Be super loud about it.

It's not like we are breaking everything for everyone either. We have
plugin versions for a reason.

Another way of avoiding this would have been to pick a different name for
this plugin. Is it too late?
On Feb 5, 2014 7:03 AM, "Ian Clelland"  wrote:

> 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
> patterns. Reads and writes can happen anywhere in a file; we can't enforce
> that a file is written out entirely in one call, so there may not be a
> point where we can say "it's done; delete the old one".
>
> It's also entirely possible for multiple readers to be open on the file,
> and for another thread to have a writer open, writing somewhere in the
> middle of the file, so I would expect race conditions.
>
> This isn't *impossible*; there have been OS filesystems which do this for a
> long time, but it seems to me to be a lot more work than writing a tool for
> developers to use for migration, and much more error prone.
>

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

[Michal Mocny]

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
release, we can make the switch -- by then, maybe we will have more
solutions for migrating.

Also, this is a nice to have, but its obviously been a situation that devs
have been living with for years.

-Michal


On Wed, Feb 5, 2014 at 10:13 AM, sebb  wrote:

> 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 knows what to migrate - we don't.\
>
> The app must tell the library what file names are involved.
> So unless the same API is used for files that are supposed to remain
> in the root, it should be possible to know what needs to move.
>
> It  may still prove too difficult to implement the merge, but perhaps
> there is some scope for adding something to help the developers.
>
> For example, the code could check if there is a file with the same
> name in the old location, and log a message if so.
> There may be other checks that would help mitigate the breakage.
>
> >
> > On Wed, Feb 5, 2014 at 9: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 implement
> >> something similar in order to make it easier for their users.
> >>
> >> Would it not be better to spend the time getting it right once, for
> >> the benfit of all developers, rather than hoping they each get it
> >> right?
> >>
> >> I don't know what is involved here, so this is theoretical.
> >> But I believe that compatibility should only be broken if necessary.
> >> Also that fixing a problem at source is usually a lot cheaper than
> >> requiring downstream developers/users to do so.
> >> There are lots more of them, so any extra effort they have to expend
> >> is multiplied many times.
> >> In other words, the cost-benefit should not just look at the immediate
> >> cost to the project.
> >>
> >> > +1 to 'go big or go home'. Break it now. Break it obviously.
> >>
> >> But I agree that breakage - if decided on - should be obvious.
> >>
> >> >
> >> > 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?
> >>
>

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

[Josh Soref]

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). Any writes are written to the "we're migrating file" if that part of 
the file exists in addition to the original. When the copy completes, we rename 
"we're migrating" to the correct file. Then we delete the original. ‎
‎
Ian wrote:
> It might be.
> The File API doesn't impose any sort of model for read/write patterns.
> Reads and writes can happen anywhere in a file;
> we can't enforce that a file is written out entirely in one call,
> so there may not be a point where we can say "it's done; delete the old one".

> It's also entirely possible for multiple readers to be open on the file,
> and for another thread to have a writer open,
> writing somewhere in the middle of the file,
> so I would expect race conditions.

> This isn't *impossible*;
> there have been OS filesystems which do this for a long time,
> but it seems to me to be a lot more work than writing a tool for developers 
> to use for migration,
> and much more error prone.

Perhaps we should start with that. Shouldn't someone write a tool which scans 
for consumers and offers a survey and let's the developer pick an answer with 
which it rewrites the file? 

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

[sebb]

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 knows what to migrate - we don't.\

The app must tell the library what file names are involved.
So unless the same API is used for files that are supposed to remain
in the root, it should be possible to know what needs to move.

It  may still prove too difficult to implement the merge, but perhaps
there is some scope for adding something to help the developers.

For example, the code could check if there is a file with the same
name in the old location, and log a message if so.
There may be other checks that would help mitigate the breakage.

>
> On Wed, Feb 5, 2014 at 9: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 implement
>> something similar in order to make it easier for their users.
>>
>> Would it not be better to spend the time getting it right once, for
>> the benfit of all developers, rather than hoping they each get it
>> right?
>>
>> I don't know what is involved here, so this is theoretical.
>> But I believe that compatibility should only be broken if necessary.
>> Also that fixing a problem at source is usually a lot cheaper than
>> requiring downstream developers/users to do so.
>> There are lots more of them, so any extra effort they have to expend
>> is multiplied many times.
>> In other words, the cost-benefit should not just look at the immediate
>> cost to the project.
>>
>> > +1 to 'go big or go home'. Break it now. Break it obviously.
>>
>> But I agree that breakage - if decided on - should be obvious.
>>
>> >
>> > 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?
>>

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

[Ian Clelland]

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
patterns. Reads and writes can happen anywhere in a file; we can't enforce
that a file is written out entirely in one call, so there may not be a
point where we can say "it's done; delete the old one".

It's also entirely possible for multiple readers to be open on the file,
and for another thread to have a writer open, writing somewhere in the
middle of the file, so I would expect race conditions.

This isn't *impossible*; there have been OS filesystems which do this for a
long time, but it seems to me to be a lot more work than writing a tool for
developers to use for migration, and much more error prone.

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

[David Kemp]

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 at 9: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 implement
> something similar in order to make it easier for their users.
>
> Would it not be better to spend the time getting it right once, for
> the benfit of all developers, rather than hoping they each get it
> right?
>
> I don't know what is involved here, so this is theoretical.
> But I believe that compatibility should only be broken if necessary.
> Also that fixing a problem at source is usually a lot cheaper than
> requiring downstream developers/users to do so.
> There are lots more of them, so any extra effort they have to expend
> is multiplied many times.
> In other words, the cost-benefit should not just look at the immediate
> cost to the project.
>
> > +1 to 'go big or go home'. Break it now. Break it obviously.
>
> But I agree that breakage - if decided on - should be obvious.
>
> >
> > 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?
>

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

[sebb]

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 it right once, for
the benfit of all developers, rather than hoping they each get it
right?

I don't know what is involved here, so this is theoretical.
But I believe that compatibility should only be broken if necessary.
Also that fixing a problem at source is usually a lot cheaper than
requiring downstream developers/users to do so.
There are lots more of them, so any extra effort they have to expend
is multiplied many times.
In other words, the cost-benefit should not just look at the immediate
cost to the project.

> +1 to 'go big or go home'. Break it now. Break it obviously.

But I agree that breakage - if decided on - should be obvious.

>
> 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?

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

[David Kemp]

-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 write completes in the new location, delete
> the old one?