Re: serving extra css
On Mon, Feb 3, 2014 at 6:58 PM, Josh Soref jso...@blackberry.com wrote: Michal wrote: Wouldn't this be better handled by Brian's dream of browser-as-a-platform? I haven¹t worked through all the details, but I don¹t think so. If you want to run the blackberry specific hooks and you browse to the app from your blackberry browser, then you¹re going to be unhappy if it¹s a different platform. If you want BB-specific hooks with BB-browser, then target BB. If you want to test your app using cordova plugins on a desktop browser simulating a mobile phone, browser-as-a-platform is the I think the way to go. If you are done building your app on desktop, and now want to test more device specific styles (such as fonts), I would say that you should test on device. Is this prohibitively difficult on BB (I have not tried so not sure what the turnaround time is)? Perhaps the app harness + some of the auto-reload-on-device work that Braden is doing will help? Browser-as-an-engine might work, maybe. I don't think so -- engine is the concept of replacing the use of the system webview, but thats still running on-device. I understand that this solves your immediate problem, but I'm not sure extending serve is really the right long term solution for this. ..also, your idea of automatically look for a well known file could be done within the application by feature detecting that its running in a desktop browser. We¹re the SDK, not the application. I could tell authors ³if you want to see the fonts, put in this magic², but I¹m hoping to avoid making each author do that (where possible). There¹s also licensing fun w/ the fonts. I suppose that I could insert some code into cordova.js instead of having serve manage the css. Would it be prehibitive to dynamically inject the style on startup from the app itself? Doing it with a link: header is a lot cleaner than inserting strange logic into cordova.js, butŠ I didn't mean cordova.js -- I meant the specific app you are using for testing. You can ship cordova-cli hooks to add this if you want to share the functionality between several apps. I'm asking: do we really need to change the tools? We can and probably will provide templates which include a style saying ³use font: Slate Pro². That¹s all you need for the platform engine. If we did use cordova.js instead of having serve provide the .css file, we¹d still need a way to get the fonts to the browser-as-engine case (which is handled by the .extra code). In case you¹re curious, installing fonts to a user¹s system is a no-go for a number of reasons (* it¹s painful to try to manage ‹ often requiring administrative privileges which isn¹t something we require, * Licensing is wrong, * it pollutes the user¹s font-space or their computer¹s font-space if shared, * it doesn¹t work if the user is visiting serve from a device other than localhost).
Re: Make cordova platform add ios work on Windows
With the app-harness, you actually can test on iOS from windows, so this is becoming a use case. So long as the pre-packaged native plugins running on the app-harness match version requirements for your app, you won't need to build the native bits locally. All we need is to serve web assets from your development machine to the AH, and the easiest way to make sure we serve the right assets is to use the platform targeted prepare step. If for no other reason, than just to make sure we serve the right cordova_plugins.js (though Braden will know what other platform bits the AH consumes, at some point it was using the app's cordova.js and plugins' js-modules, but I think it changed to used the AH bundled versions). -Michal On Mon, Feb 3, 2014 at 12:50 PM, Jesse purplecabb...@gmail.com wrote: Personally, I would not expect a multi-platform team to even checkin the platforms folder. Addressing Axel's use case: It would only require a few commands to be ready to build an iOS Cordova project: npm install -g cordova cordova create ~/HelloCordova cd ~/HelloCordova cordova platform add ios As an alternative, the phonegap-cli [1] allows actual building of iOS targets from Windows, by using the phonegap-build service. Or you could just use the PhoneGap build site directly. You would need to setup an account either way, My reason for creating the issue CB-5963 was NOT to enable the functionality Baz referred to with CB-5706, but to provide an easy way to test plugins in WP7/8 and Windows8. I will/am changing the functionality a bit in the nodejs scripts because it doesn't make sense to platform add ios on windows because you won't be able to run the tests anyway. My plan is that the node script for testing mobile spec will only platform add whatever platform is specified in the arguments. ie. node createmobilespec.js --platform wp8 and possibly in the future, allow the testing of specific plugins, from specific locations, using a specific cordova, and a specific platform location. This really is all I have to say on the CB-5706 subject, if you still want to do it, then go ahead. However, if it is a significant change, and I think I'll have to support the added code in wp8/windows8, then I will be very strict in accepting pull requests as I work on these projects every day. You may want to choose a less controversial issue to work on. [1] https://github.com/phonegap/phonegap-cli [2] https://build.phonegap.com/ @purplecabbage risingj.com On Mon, Feb 3, 2014 at 8:09 AM, Andrew Grieve agri...@chromium.org wrote: Converting the scripts to node is exactly what we'd need to do to have them work on Win, I think. We can just remove the call to check_reqs made from create(). A use-case I can see for this is PhoneGap Build / AppHarness development. If you'd like to work on this issue, then I think that's great! On Sun, Feb 2, 2014 at 9:20 AM, Bas Bosman m...@nazgul.nu wrote: I do think it's beneficial to have that option available on Windows. As far as i know Cordova strives for feature parity across all deployment platforms (where possible) and I don't think it's strange to extend that feature parity to the development platform (where possible). I agree that you need XCode to build, test and deploy an iOS app, but you don't need it for large parts of developing the app. For that same reason I think that the ability to do a cordova add wp8 (not build) on a Mac for example would be a good thing to have as well. The 'platform add' code currently doesn't actually use any of the things checked for in check_req as far as I can tell, so there is no technical reason not to do it. And we do allow a 'plugin add' to add iOS specific stuff on a Windows machine. If a group of people start developing a multi platform app using Cordova a valid use case in my opinion would be that there is one developer who does the initial setup. So adding the base platforms and plugins for the team to use. Currently he has to use multiple development platforms, which he may not have, to do so while there is a good chance he'll only be working on the on Mac or Windows only development parts of the app after that initial setup. Giving him the opportunity to do that all from the environment he's familiar with seems like a nice thing to have. Another reason I started looking into this is mobile-spec. There is a JIRA issue (CB-5963, submitted by a core contributor) about createmobilespec.sh only working on a Mac. That script wouldn't be to hard to port over to JavaScript to have it run on other platforms as well, but it also has a dependency on the platform add ios stuff. I think that having something there that works on all platforms and produces the same end result would be a good thing as well. And I agree with Axel, although I hadn't thought of it before, that
Re: Make cordova platform add ios work on Windows
..matter of fact, for those same reasons we should change the other platforms to support installation when check_reqs fail. I should be able to test Android using AH the exact same way without a full dev environment. On Tue, Feb 4, 2014 at 9:27 AM, Michal Mocny mmo...@chromium.org wrote: With the app-harness, you actually can test on iOS from windows, so this is becoming a use case. So long as the pre-packaged native plugins running on the app-harness match version requirements for your app, you won't need to build the native bits locally. All we need is to serve web assets from your development machine to the AH, and the easiest way to make sure we serve the right assets is to use the platform targeted prepare step. If for no other reason, than just to make sure we serve the right cordova_plugins.js (though Braden will know what other platform bits the AH consumes, at some point it was using the app's cordova.js and plugins' js-modules, but I think it changed to used the AH bundled versions). -Michal On Mon, Feb 3, 2014 at 12:50 PM, Jesse purplecabb...@gmail.com wrote: Personally, I would not expect a multi-platform team to even checkin the platforms folder. Addressing Axel's use case: It would only require a few commands to be ready to build an iOS Cordova project: npm install -g cordova cordova create ~/HelloCordova cd ~/HelloCordova cordova platform add ios As an alternative, the phonegap-cli [1] allows actual building of iOS targets from Windows, by using the phonegap-build service. Or you could just use the PhoneGap build site directly. You would need to setup an account either way, My reason for creating the issue CB-5963 was NOT to enable the functionality Baz referred to with CB-5706, but to provide an easy way to test plugins in WP7/8 and Windows8. I will/am changing the functionality a bit in the nodejs scripts because it doesn't make sense to platform add ios on windows because you won't be able to run the tests anyway. My plan is that the node script for testing mobile spec will only platform add whatever platform is specified in the arguments. ie. node createmobilespec.js --platform wp8 and possibly in the future, allow the testing of specific plugins, from specific locations, using a specific cordova, and a specific platform location. This really is all I have to say on the CB-5706 subject, if you still want to do it, then go ahead. However, if it is a significant change, and I think I'll have to support the added code in wp8/windows8, then I will be very strict in accepting pull requests as I work on these projects every day. You may want to choose a less controversial issue to work on. [1] https://github.com/phonegap/phonegap-cli [2] https://build.phonegap.com/ @purplecabbage risingj.com On Mon, Feb 3, 2014 at 8:09 AM, Andrew Grieve agri...@chromium.org wrote: Converting the scripts to node is exactly what we'd need to do to have them work on Win, I think. We can just remove the call to check_reqs made from create(). A use-case I can see for this is PhoneGap Build / AppHarness development. If you'd like to work on this issue, then I think that's great! On Sun, Feb 2, 2014 at 9:20 AM, Bas Bosman m...@nazgul.nu wrote: I do think it's beneficial to have that option available on Windows. As far as i know Cordova strives for feature parity across all deployment platforms (where possible) and I don't think it's strange to extend that feature parity to the development platform (where possible). I agree that you need XCode to build, test and deploy an iOS app, but you don't need it for large parts of developing the app. For that same reason I think that the ability to do a cordova add wp8 (not build) on a Mac for example would be a good thing to have as well. The 'platform add' code currently doesn't actually use any of the things checked for in check_req as far as I can tell, so there is no technical reason not to do it. And we do allow a 'plugin add' to add iOS specific stuff on a Windows machine. If a group of people start developing a multi platform app using Cordova a valid use case in my opinion would be that there is one developer who does the initial setup. So adding the base platforms and plugins for the team to use. Currently he has to use multiple development platforms, which he may not have, to do so while there is a good chance he'll only be working on the on Mac or Windows only development parts of the app after that initial setup. Giving him the opportunity to do that all from the environment he's familiar with seems like a nice thing to have. Another reason I started looking into this is mobile-spec. There is a JIRA issue (CB-5963, submitted by a core contributor) about createmobilespec.sh only working on a Mac. That script wouldn't be to hard to port over to JavaScript to have
Re: Make cordova platform add ios work on Windows
In that case, I feel like we should be calling check_reqs on create, but not throwing an error; just display a warning if the build tools aren't installed. We've had reports from people using the cca toolchain that `create` lets them start the project, but then they can't build because they're missing javac or something else essential. I think there's an expectation that we at least let people know early if they're going to have a bad time later on. On Tue, Feb 4, 2014 at 9:30 AM, Michal Mocny mmo...@chromium.org wrote: ..matter of fact, for those same reasons we should change the other platforms to support installation when check_reqs fail. I should be able to test Android using AH the exact same way without a full dev environment. On Tue, Feb 4, 2014 at 9:27 AM, Michal Mocny mmo...@chromium.org wrote: With the app-harness, you actually can test on iOS from windows, so this is becoming a use case. So long as the pre-packaged native plugins running on the app-harness match version requirements for your app, you won't need to build the native bits locally. All we need is to serve web assets from your development machine to the AH, and the easiest way to make sure we serve the right assets is to use the platform targeted prepare step. If for no other reason, than just to make sure we serve the right cordova_plugins.js (though Braden will know what other platform bits the AH consumes, at some point it was using the app's cordova.js and plugins' js-modules, but I think it changed to used the AH bundled versions). -Michal On Mon, Feb 3, 2014 at 12:50 PM, Jesse purplecabb...@gmail.com wrote: Personally, I would not expect a multi-platform team to even checkin the platforms folder. Addressing Axel's use case: It would only require a few commands to be ready to build an iOS Cordova project: npm install -g cordova cordova create ~/HelloCordova cd ~/HelloCordova cordova platform add ios As an alternative, the phonegap-cli [1] allows actual building of iOS targets from Windows, by using the phonegap-build service. Or you could just use the PhoneGap build site directly. You would need to setup an account either way, My reason for creating the issue CB-5963 was NOT to enable the functionality Baz referred to with CB-5706, but to provide an easy way to test plugins in WP7/8 and Windows8. I will/am changing the functionality a bit in the nodejs scripts because it doesn't make sense to platform add ios on windows because you won't be able to run the tests anyway. My plan is that the node script for testing mobile spec will only platform add whatever platform is specified in the arguments. ie. node createmobilespec.js --platform wp8 and possibly in the future, allow the testing of specific plugins, from specific locations, using a specific cordova, and a specific platform location. This really is all I have to say on the CB-5706 subject, if you still want to do it, then go ahead. However, if it is a significant change, and I think I'll have to support the added code in wp8/windows8, then I will be very strict in accepting pull requests as I work on these projects every day. You may want to choose a less controversial issue to work on. [1] https://github.com/phonegap/phonegap-cli [2] https://build.phonegap.com/ @purplecabbage risingj.com On Mon, Feb 3, 2014 at 8:09 AM, Andrew Grieve agri...@chromium.org wrote: Converting the scripts to node is exactly what we'd need to do to have them work on Win, I think. We can just remove the call to check_reqs made from create(). A use-case I can see for this is PhoneGap Build / AppHarness development. If you'd like to work on this issue, then I think that's great! On Sun, Feb 2, 2014 at 9:20 AM, Bas Bosman m...@nazgul.nu wrote: I do think it's beneficial to have that option available on Windows. As far as i know Cordova strives for feature parity across all deployment platforms (where possible) and I don't think it's strange to extend that feature parity to the development platform (where possible). I agree that you need XCode to build, test and deploy an iOS app, but you don't need it for large parts of developing the app. For that same reason I think that the ability to do a cordova add wp8 (not build) on a Mac for example would be a good thing to have as well. The 'platform add' code currently doesn't actually use any of the things checked for in check_req as far as I can tell, so there is no technical reason not to do it. And we do allow a 'plugin add' to add iOS specific stuff on a Windows machine. If a group of people start developing a multi platform app using Cordova a valid use case in my opinion would be that there is one developer who does the initial setup. So adding the base
Re: Make cordova platform add ios work on Windows
I think we've previously also thrown around the idea of Installed vs Enabled (though the context I think was about plugins and being conditionally disabled on various platforms). Perhaps we could always install the platforms you ask for, but leave then disabled for local builds until check_req's pass? On Tue, Feb 4, 2014 at 9:37 AM, Ian Clelland iclell...@chromium.org wrote: In that case, I feel like we should be calling check_reqs on create, but not throwing an error; just display a warning if the build tools aren't installed. We've had reports from people using the cca toolchain that `create` lets them start the project, but then they can't build because they're missing javac or something else essential. I think there's an expectation that we at least let people know early if they're going to have a bad time later on. On Tue, Feb 4, 2014 at 9:30 AM, Michal Mocny mmo...@chromium.org wrote: ..matter of fact, for those same reasons we should change the other platforms to support installation when check_reqs fail. I should be able to test Android using AH the exact same way without a full dev environment. On Tue, Feb 4, 2014 at 9:27 AM, Michal Mocny mmo...@chromium.org wrote: With the app-harness, you actually can test on iOS from windows, so this is becoming a use case. So long as the pre-packaged native plugins running on the app-harness match version requirements for your app, you won't need to build the native bits locally. All we need is to serve web assets from your development machine to the AH, and the easiest way to make sure we serve the right assets is to use the platform targeted prepare step. If for no other reason, than just to make sure we serve the right cordova_plugins.js (though Braden will know what other platform bits the AH consumes, at some point it was using the app's cordova.js and plugins' js-modules, but I think it changed to used the AH bundled versions). -Michal On Mon, Feb 3, 2014 at 12:50 PM, Jesse purplecabb...@gmail.com wrote: Personally, I would not expect a multi-platform team to even checkin the platforms folder. Addressing Axel's use case: It would only require a few commands to be ready to build an iOS Cordova project: npm install -g cordova cordova create ~/HelloCordova cd ~/HelloCordova cordova platform add ios As an alternative, the phonegap-cli [1] allows actual building of iOS targets from Windows, by using the phonegap-build service. Or you could just use the PhoneGap build site directly. You would need to setup an account either way, My reason for creating the issue CB-5963 was NOT to enable the functionality Baz referred to with CB-5706, but to provide an easy way to test plugins in WP7/8 and Windows8. I will/am changing the functionality a bit in the nodejs scripts because it doesn't make sense to platform add ios on windows because you won't be able to run the tests anyway. My plan is that the node script for testing mobile spec will only platform add whatever platform is specified in the arguments. ie. node createmobilespec.js --platform wp8 and possibly in the future, allow the testing of specific plugins, from specific locations, using a specific cordova, and a specific platform location. This really is all I have to say on the CB-5706 subject, if you still want to do it, then go ahead. However, if it is a significant change, and I think I'll have to support the added code in wp8/windows8, then I will be very strict in accepting pull requests as I work on these projects every day. You may want to choose a less controversial issue to work on. [1] https://github.com/phonegap/phonegap-cli [2] https://build.phonegap.com/ @purplecabbage risingj.com On Mon, Feb 3, 2014 at 8:09 AM, Andrew Grieve agri...@chromium.org wrote: Converting the scripts to node is exactly what we'd need to do to have them work on Win, I think. We can just remove the call to check_reqs made from create(). A use-case I can see for this is PhoneGap Build / AppHarness development. If you'd like to work on this issue, then I think that's great! On Sun, Feb 2, 2014 at 9:20 AM, Bas Bosman m...@nazgul.nu wrote: I do think it's beneficial to have that option available on Windows. As far as i know Cordova strives for feature parity across all deployment platforms (where possible) and I don't think it's strange to extend that feature parity to the development platform (where possible). I agree that you need XCode to build, test and deploy an iOS app, but you don't need it for large parts of developing the app. For that same reason I think that the ability to do a cordova add wp8 (not build) on a Mac for example would be a good thing to have as well. The 'platform add' code currently doesn't actually use any of the things
Re: New release of the cordova-plugin-file
File still has a couple of rough edges, but it's been getting use in the wild recently. Exposure to a wider audience would probably help us work out the remainder of the issues. Ian On Mon, Feb 3, 2014 at 11:11 AM, Andrew Grieve agri...@chromium.org wrote: Ian's off today, but I'm definitely in support of doing a plugins release this week with it included. On Mon, Feb 3, 2014 at 9:41 AM, Maxim Ermilov maxim.ermi...@canonical.comwrote: Hey guys, I noticed the cordova-plugin-file was released 3 months ago. Could we plan for a new release soon? This would be to enable Ubuntu support, which has been merged for a bit. _ Best regards, Maxim Ermilov
Re: Make cordova platform add ios work on Windows
For the record, the App Harness makes child apps use the cordova.js, cordova_plugins.js, and plugins/* which are included with the App Harness, not the ones that come with the child app. This is because it ensures compatibility with the native code and the Javascript side, though it can break the JS API for a plugin if there's a version mismatch (which the App Harness can warn about). Generally these APIs are more stable than the bridge calls the plugin is making under the hood, hence the decision to use the bundled JS code. Braden On Tue, Feb 4, 2014 at 9:44 AM, Michal Mocny mmo...@chromium.org wrote: I think we've previously also thrown around the idea of Installed vs Enabled (though the context I think was about plugins and being conditionally disabled on various platforms). Perhaps we could always install the platforms you ask for, but leave then disabled for local builds until check_req's pass? On Tue, Feb 4, 2014 at 9:37 AM, Ian Clelland iclell...@chromium.org wrote: In that case, I feel like we should be calling check_reqs on create, but not throwing an error; just display a warning if the build tools aren't installed. We've had reports from people using the cca toolchain that `create` lets them start the project, but then they can't build because they're missing javac or something else essential. I think there's an expectation that we at least let people know early if they're going to have a bad time later on. On Tue, Feb 4, 2014 at 9:30 AM, Michal Mocny mmo...@chromium.org wrote: ..matter of fact, for those same reasons we should change the other platforms to support installation when check_reqs fail. I should be able to test Android using AH the exact same way without a full dev environment. On Tue, Feb 4, 2014 at 9:27 AM, Michal Mocny mmo...@chromium.org wrote: With the app-harness, you actually can test on iOS from windows, so this is becoming a use case. So long as the pre-packaged native plugins running on the app-harness match version requirements for your app, you won't need to build the native bits locally. All we need is to serve web assets from your development machine to the AH, and the easiest way to make sure we serve the right assets is to use the platform targeted prepare step. If for no other reason, than just to make sure we serve the right cordova_plugins.js (though Braden will know what other platform bits the AH consumes, at some point it was using the app's cordova.js and plugins' js-modules, but I think it changed to used the AH bundled versions). -Michal On Mon, Feb 3, 2014 at 12:50 PM, Jesse purplecabb...@gmail.com wrote: Personally, I would not expect a multi-platform team to even checkin the platforms folder. Addressing Axel's use case: It would only require a few commands to be ready to build an iOS Cordova project: npm install -g cordova cordova create ~/HelloCordova cd ~/HelloCordova cordova platform add ios As an alternative, the phonegap-cli [1] allows actual building of iOS targets from Windows, by using the phonegap-build service. Or you could just use the PhoneGap build site directly. You would need to setup an account either way, My reason for creating the issue CB-5963 was NOT to enable the functionality Baz referred to with CB-5706, but to provide an easy way to test plugins in WP7/8 and Windows8. I will/am changing the functionality a bit in the nodejs scripts because it doesn't make sense to platform add ios on windows because you won't be able to run the tests anyway. My plan is that the node script for testing mobile spec will only platform add whatever platform is specified in the arguments. ie. node createmobilespec.js --platform wp8 and possibly in the future, allow the testing of specific plugins, from specific locations, using a specific cordova, and a specific platform location. This really is all I have to say on the CB-5706 subject, if you still want to do it, then go ahead. However, if it is a significant change, and I think I'll have to support the added code in wp8/windows8, then I will be very strict in accepting pull requests as I work on these projects every day. You may want to choose a less controversial issue to work on. [1] https://github.com/phonegap/phonegap-cli [2] https://build.phonegap.com/ @purplecabbage risingj.com On Mon, Feb 3, 2014 at 8:09 AM, Andrew Grieve agri...@chromium.org wrote: Converting the scripts to node is exactly what we'd need to do to have them work on Win, I think. We can just remove the call to check_reqs made from create(). A use-case I can see for this is PhoneGap Build / AppHarness development. If you'd like to work on this issue, then I think that's great! On Sun, Feb
Re: Make cordova platform add ios work on Windows
It doesn't use the app's cordova_plugins.js? I thought we wanted to verify that the right set of plugins are installed and to do that we need to load the apps' version. If we are doing that for now thats fine, but I'm curious if that is the long term plan? Are we loading *any* assets outside of whats available in the top level www/? Once upon a time serve served up the top level www/, then changed to platform www/.. should we change it back? I'm with Jesse that devs should not need (but can if they want) to version control platforms/ or plugins/, and his workaround seems quite agreeable to me. -Michal On Tue, Feb 4, 2014 at 11:23 AM, Braden Shepherdson bra...@chromium.orgwrote: For the record, the App Harness makes child apps use the cordova.js, cordova_plugins.js, and plugins/* which are included with the App Harness, not the ones that come with the child app. This is because it ensures compatibility with the native code and the Javascript side, though it can break the JS API for a plugin if there's a version mismatch (which the App Harness can warn about). Generally these APIs are more stable than the bridge calls the plugin is making under the hood, hence the decision to use the bundled JS code. Braden On Tue, Feb 4, 2014 at 9:44 AM, Michal Mocny mmo...@chromium.org wrote: I think we've previously also thrown around the idea of Installed vs Enabled (though the context I think was about plugins and being conditionally disabled on various platforms). Perhaps we could always install the platforms you ask for, but leave then disabled for local builds until check_req's pass? On Tue, Feb 4, 2014 at 9:37 AM, Ian Clelland iclell...@chromium.org wrote: In that case, I feel like we should be calling check_reqs on create, but not throwing an error; just display a warning if the build tools aren't installed. We've had reports from people using the cca toolchain that `create` lets them start the project, but then they can't build because they're missing javac or something else essential. I think there's an expectation that we at least let people know early if they're going to have a bad time later on. On Tue, Feb 4, 2014 at 9:30 AM, Michal Mocny mmo...@chromium.org wrote: ..matter of fact, for those same reasons we should change the other platforms to support installation when check_reqs fail. I should be able to test Android using AH the exact same way without a full dev environment. On Tue, Feb 4, 2014 at 9:27 AM, Michal Mocny mmo...@chromium.org wrote: With the app-harness, you actually can test on iOS from windows, so this is becoming a use case. So long as the pre-packaged native plugins running on the app-harness match version requirements for your app, you won't need to build the native bits locally. All we need is to serve web assets from your development machine to the AH, and the easiest way to make sure we serve the right assets is to use the platform targeted prepare step. If for no other reason, than just to make sure we serve the right cordova_plugins.js (though Braden will know what other platform bits the AH consumes, at some point it was using the app's cordova.js and plugins' js-modules, but I think it changed to used the AH bundled versions). -Michal On Mon, Feb 3, 2014 at 12:50 PM, Jesse purplecabb...@gmail.com wrote: Personally, I would not expect a multi-platform team to even checkin the platforms folder. Addressing Axel's use case: It would only require a few commands to be ready to build an iOS Cordova project: npm install -g cordova cordova create ~/HelloCordova cd ~/HelloCordova cordova platform add ios As an alternative, the phonegap-cli [1] allows actual building of iOS targets from Windows, by using the phonegap-build service. Or you could just use the PhoneGap build site directly. You would need to setup an account either way, My reason for creating the issue CB-5963 was NOT to enable the functionality Baz referred to with CB-5706, but to provide an easy way to test plugins in WP7/8 and Windows8. I will/am changing the functionality a bit in the nodejs scripts because it doesn't make sense to platform add ios on windows because you won't be able to run the tests anyway. My plan is that the node script for testing mobile spec will only platform add whatever platform is specified in the arguments. ie. node createmobilespec.js --platform wp8 and possibly in the future, allow the testing of specific plugins, from specific locations, using a specific cordova, and a specific platform location. This really is all I have to say on the CB-5706 subject, if you still want to do it, then go ahead. However, if it is a significant change, and I think I'll have to support the added code in wp8/windows8, then I will be very
Re: Make cordova platform add ios work on Windows
We use the App Harness' versions of cordova.js, cordova_plugins.js, and plugins/*, as I stated. We *fetch* the child app's cordova_plugins.js in order to read the plugin version data and compare with the versions installed in the App Harness, but when you launch the app it uses the App Harness' version, because we want to ensure compatibility at the more fragile and dangerous of the two layers: exec() calls. Braden On Tue, Feb 4, 2014 at 11:53 AM, Michal Mocny mmo...@chromium.org wrote: It doesn't use the app's cordova_plugins.js? I thought we wanted to verify that the right set of plugins are installed and to do that we need to load the apps' version. If we are doing that for now thats fine, but I'm curious if that is the long term plan? Are we loading *any* assets outside of whats available in the top level www/? Once upon a time serve served up the top level www/, then changed to platform www/.. should we change it back? I'm with Jesse that devs should not need (but can if they want) to version control platforms/ or plugins/, and his workaround seems quite agreeable to me. -Michal On Tue, Feb 4, 2014 at 11:23 AM, Braden Shepherdson bra...@chromium.orgwrote: For the record, the App Harness makes child apps use the cordova.js, cordova_plugins.js, and plugins/* which are included with the App Harness, not the ones that come with the child app. This is because it ensures compatibility with the native code and the Javascript side, though it can break the JS API for a plugin if there's a version mismatch (which the App Harness can warn about). Generally these APIs are more stable than the bridge calls the plugin is making under the hood, hence the decision to use the bundled JS code. Braden On Tue, Feb 4, 2014 at 9:44 AM, Michal Mocny mmo...@chromium.org wrote: I think we've previously also thrown around the idea of Installed vs Enabled (though the context I think was about plugins and being conditionally disabled on various platforms). Perhaps we could always install the platforms you ask for, but leave then disabled for local builds until check_req's pass? On Tue, Feb 4, 2014 at 9:37 AM, Ian Clelland iclell...@chromium.org wrote: In that case, I feel like we should be calling check_reqs on create, but not throwing an error; just display a warning if the build tools aren't installed. We've had reports from people using the cca toolchain that `create` lets them start the project, but then they can't build because they're missing javac or something else essential. I think there's an expectation that we at least let people know early if they're going to have a bad time later on. On Tue, Feb 4, 2014 at 9:30 AM, Michal Mocny mmo...@chromium.org wrote: ..matter of fact, for those same reasons we should change the other platforms to support installation when check_reqs fail. I should be able to test Android using AH the exact same way without a full dev environment. On Tue, Feb 4, 2014 at 9:27 AM, Michal Mocny mmo...@chromium.org wrote: With the app-harness, you actually can test on iOS from windows, so this is becoming a use case. So long as the pre-packaged native plugins running on the app-harness match version requirements for your app, you won't need to build the native bits locally. All we need is to serve web assets from your development machine to the AH, and the easiest way to make sure we serve the right assets is to use the platform targeted prepare step. If for no other reason, than just to make sure we serve the right cordova_plugins.js (though Braden will know what other platform bits the AH consumes, at some point it was using the app's cordova.js and plugins' js-modules, but I think it changed to used the AH bundled versions). -Michal On Mon, Feb 3, 2014 at 12:50 PM, Jesse purplecabb...@gmail.com wrote: Personally, I would not expect a multi-platform team to even checkin the platforms folder. Addressing Axel's use case: It would only require a few commands to be ready to build an iOS Cordova project: npm install -g cordova cordova create ~/HelloCordova cd ~/HelloCordova cordova platform add ios As an alternative, the phonegap-cli [1] allows actual building of iOS targets from Windows, by using the phonegap-build service. Or you could just use the PhoneGap build site directly. You would need to setup an account either way, My reason for creating the issue CB-5963 was NOT to enable the functionality Baz referred to with CB-5706, but to provide an easy way to test plugins in WP7/8 and Windows8. I will/am changing the functionality a bit in the nodejs scripts because it doesn't make sense to platform add ios on windows because you won't be able to run the tests anyway. My plan is that the node script for testing mobile spec will only platform
Re: serving extra css
Do not feel this is our territory to override. The end dev should be adding the fonts they want in their app. On Tue, Feb 4, 2014 at 6:13 AM, Michal Mocny mmo...@chromium.org wrote: On Mon, Feb 3, 2014 at 6:58 PM, Josh Soref jso...@blackberry.com wrote: Michal wrote: Wouldn't this be better handled by Brian's dream of browser-as-a-platform? I haven¹t worked through all the details, but I don¹t think so. If you want to run the blackberry specific hooks and you browse to the app from your blackberry browser, then you¹re going to be unhappy if it¹s a different platform. If you want BB-specific hooks with BB-browser, then target BB. If you want to test your app using cordova plugins on a desktop browser simulating a mobile phone, browser-as-a-platform is the I think the way to go. If you are done building your app on desktop, and now want to test more device specific styles (such as fonts), I would say that you should test on device. Is this prohibitively difficult on BB (I have not tried so not sure what the turnaround time is)? Perhaps the app harness + some of the auto-reload-on-device work that Braden is doing will help? Browser-as-an-engine might work, maybe. I don't think so -- engine is the concept of replacing the use of the system webview, but thats still running on-device. I understand that this solves your immediate problem, but I'm not sure extending serve is really the right long term solution for this. ..also, your idea of automatically look for a well known file could be done within the application by feature detecting that its running in a desktop browser. We¹re the SDK, not the application. I could tell authors ³if you want to see the fonts, put in this magic², but I¹m hoping to avoid making each author do that (where possible). There¹s also licensing fun w/ the fonts. I suppose that I could insert some code into cordova.js instead of having serve manage the css. Would it be prehibitive to dynamically inject the style on startup from the app itself? Doing it with a link: header is a lot cleaner than inserting strange logic into cordova.js, butŠ I didn't mean cordova.js -- I meant the specific app you are using for testing. You can ship cordova-cli hooks to add this if you want to share the functionality between several apps. I'm asking: do we really need to change the tools? We can and probably will provide templates which include a style saying ³use font: Slate Pro². That¹s all you need for the platform engine. If we did use cordova.js instead of having serve provide the .css file, we¹d still need a way to get the fonts to the browser-as-engine case (which is handled by the .extra code). In case you¹re curious, installing fonts to a user¹s system is a no-go for a number of reasons (* it¹s painful to try to manage ‹ often requiring administrative privileges which isn¹t something we require, * Licensing is wrong, * it pollutes the user¹s font-space or their computer¹s font-space if shared, * it doesn¹t work if the user is visiting serve from a device other than localhost).
Jira permissions
We have a new intern joining our group, Martin Canuto Gonzalez Gonzalez. Could someone with Jira admin grant him the permission to own Jira items? His Jira id is: martin.c.glez.glez He'll start by working on some doc issues. Thanks!
Re: Jira permissions
done On Tue, Feb 4, 2014 at 10:35 AM, Marcel Kinard cmarc...@gmail.com wrote: We have a new intern joining our group, Martin Canuto Gonzalez Gonzalez. Could someone with Jira admin grant him the permission to own Jira items? His Jira id is: martin.c.glez.glez He'll start by working on some doc issues. Thanks!
Android/amazon-fireos: web view callbacks
Hi, Devs There are 2 classes - CordovaWebViewClient and CordovaChromeClient in amazon-fireos repo. They basically handle WebView callbacks. Recently, while using Cordova internally for our projects we needed to handle few more callbacks and noticed they were missing. I was wondering if there is any reason why some callbacks were not handled? If not, I am cool. I would like to add the ones we need for now so want to make sure I am not missing anything. :) Also, one more thing, we would like to pass on these callbacks to plugins incase they want to handle it. If no plugin wants handle it then callback handling will fallback to the default cordova one. Please let me know your thoughts. Thanks Archana
Re: Plugins Release!
I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil...@gmail.com wrote: Hey All, What is the general feeling on me moving forward with a plugins release today? I could start the process this afternoon if there aren't any objections or concerns. Are there any plugins that shouldn't be released?
Re: Android/amazon-fireos: web view callbacks
Which callbacks are we talking about? On Tue, Feb 4, 2014 at 11:20 AM, Naik, Archana na...@lab126.com wrote: Hi, Devs There are 2 classes - CordovaWebViewClient and CordovaChromeClient in amazon-fireos repo. They basically handle WebView callbacks. Recently, while using Cordova internally for our projects we needed to handle few more callbacks and noticed they were missing. I was wondering if there is any reason why some callbacks were not handled? If not, I am cool. I would like to add the ones we need for now so want to make sure I am not missing anything. :) Also, one more thing, we would like to pass on these callbacks to plugins incase they want to handle it. If no plugin wants handle it then callback handling will fallback to the default cordova one. Please let me know your thoughts. Thanks Archana
Re: Android/amazon-fireos: web view callbacks
Which callbacks in particular are missing? There are some callbacks we don't touch because they can break the WebView. These can include anything that handles gestures (which when done wrong, can break touch events), and other view related callbacks. I'd highly recommend writing tests for the existing behaviour before adding the callbacks, since we've had very bad luck with this in the past w.r.t. the back button. On Tue, Feb 4, 2014 at 11:20 AM, Naik, Archana na...@lab126.com wrote: Hi, Devs There are 2 classes - CordovaWebViewClient and CordovaChromeClient in amazon-fireos repo. They basically handle WebView callbacks. Recently, while using Cordova internally for our projects we needed to handle few more callbacks and noticed they were missing. I was wondering if there is any reason why some callbacks were not handled? If not, I am cool. I would like to add the ones we need for now so want to make sure I am not missing anything. :) Also, one more thing, we would like to pass on these callbacks to plugins incase they want to handle it. If no plugin wants handle it then callback handling will fallback to the default cordova one. Please let me know your thoughts. Thanks Archana
Re: Plugins Release!
Sounds good! On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill stevengil...@gmail.com wrote: I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil...@gmail.com wrote: Hey All, What is the general feeling on me moving forward with a plugins release today? I could start the process this afternoon if there aren't any objections or concerns. Are there any plugins that shouldn't be released?
Re: Android/amazon-fireos: web view callbacks
So for example, onCreateWindow() or onProgressChanged(). We might need to add onCreateWindow() but onProgressChanged() not that urgent. More importantly, we want to let plugins handle there callbacks first and incase they don't we want to fallback on default handlers in these classes. Archana On 2/4/14 11:29 AM, Joe Bowser bows...@gmail.com wrote: Which callbacks in particular are missing? There are some callbacks we don't touch because they can break the WebView. These can include anything that handles gestures (which when done wrong, can break touch events), and other view related callbacks. I'd highly recommend writing tests for the existing behaviour before adding the callbacks, since we've had very bad luck with this in the past w.r.t. the back button. On Tue, Feb 4, 2014 at 11:20 AM, Naik, Archana na...@lab126.com wrote: Hi, Devs There are 2 classes - CordovaWebViewClient and CordovaChromeClient in amazon-fireos repo. They basically handle WebView callbacks. Recently, while using Cordova internally for our projects we needed to handle few more callbacks and noticed they were missing. I was wondering if there is any reason why some callbacks were not handled? If not, I am cool. I would like to add the ones we need for now so want to make sure I am not missing anything. :) Also, one more thing, we would like to pass on these callbacks to plugins incase they want to handle it. If no plugin wants handle it then callback handling will fallback to the default cordova one. Please let me know your thoughts. Thanks Archana
Introducing myself
Hi everyone! My name is Martin Gonzalez, I work in the IBM Mobile Foundation, and my job role it's help and contribute with this amazing project that Cordova is. I really want to contribute to the success and development in any way possible. You may already know some folks, that I'm working with (Marcel Kinard, Michael Billau, James Jong, Lisa Deluca). I have good command using Javascript, Java, C/C++, HTML and another languages, however, I don't have much experience with Cordova yet, but I'm really focused on increase my knowledge and expertise. If you have any questions, please feel free to contact me. Thanks. Martin Gonzalez.
Re: Introducing myself
Welcome Martin! Glad to have you here and feel free to bug the list for help anytime. =) On Tue, Feb 4, 2014 at 12:42 PM, Martin Gonzalez Glez martin.c.glez.g...@gmail.com wrote: Hi everyone! My name is Martin Gonzalez, I work in the IBM Mobile Foundation, and my job role it's help and contribute with this amazing project that Cordova is. I really want to contribute to the success and development in any way possible. You may already know some folks, that I'm working with (Marcel Kinard, Michael Billau, James Jong, Lisa Deluca). I have good command using Javascript, Java, C/C++, HTML and another languages, however, I don't have much experience with Cordova yet, but I'm really focused on increase my knowledge and expertise. If you have any questions, please feel free to contact me. Thanks. Martin Gonzalez.
Odd tags
The tag name appears to be 3.3.4-rc.1, but the release notes seem to be 3.4.0-rc.1, is the tag errant? cordova-cli $ git show 3.3.4-rc.1 commit 81ac7f90af279f54cea38d8927fa389504e062ba Author: Steven Gill stevengil...@gmail.com Date: Thu Jan 30 17:36:28 2014 -0800 updated release notes diff --git a/RELEASENOTES.md b/RELEASENOTES.md index 8400962..a28ffe1 100644 --- a/RELEASENOTES.md +++ b/RELEASENOTES.md @@ -20,6 +20,11 @@ -- # Cordova-cli Release Notes +## 3.4.0-rc.1 +* updated to 3.4.0-rc.1 +* added firefoxos to readme +* updated release notes + ## 3.3.1-0.3.0 (Jan 30, 2015) * Setting version to 3.3.1-0.3.0; updated plugman reference to 0.19.0 * CB-5913 Fail more gracefully on Windows when symlinks fail.
Re: Introducing myself
Hi Martin, welcome! On Tue, Feb 4, 2014 at 12:52 PM, Brian LeRoux b...@brian.io wrote: Welcome Martin! Glad to have you here and feel free to bug the list for help anytime. =) On Tue, Feb 4, 2014 at 12:42 PM, Martin Gonzalez Glez martin.c.glez.g...@gmail.com wrote: Hi everyone! My name is Martin Gonzalez, I work in the IBM Mobile Foundation, and my job role it's help and contribute with this amazing project that Cordova is. I really want to contribute to the success and development in any way possible. You may already know some folks, that I'm working with (Marcel Kinard, Michael Billau, James Jong, Lisa Deluca). I have good command using Javascript, Java, C/C++, HTML and another languages, however, I don't have much experience with Cordova yet, but I'm really focused on increase my knowledge and expertise. If you have any questions, please feel free to contact me. Thanks. Martin Gonzalez.
Re: Odd tags
ahh yes, it is supposed to be 3.4.0-rc.1 I will fix that now On Tue, Feb 4, 2014 at 1:25 PM, Josh Soref jso...@blackberry.com wrote: The tag name appears to be 3.3.4-rc.1, but the release notes seem to be 3.4.0-rc.1, is the tag errant? cordova-cli $ git show 3.3.4-rc.1 commit 81ac7f90af279f54cea38d8927fa389504e062ba Author: Steven Gill stevengil...@gmail.com Date: Thu Jan 30 17:36:28 2014 -0800 updated release notes diff --git a/RELEASENOTES.md b/RELEASENOTES.md index 8400962..a28ffe1 100644 --- a/RELEASENOTES.md +++ b/RELEASENOTES.md @@ -20,6 +20,11 @@ -- # Cordova-cli Release Notes +## 3.4.0-rc.1 +* updated to 3.4.0-rc.1 +* added firefoxos to readme +* updated release notes + ## 3.3.1-0.3.0 (Jan 30, 2015) * Setting version to 3.3.1-0.3.0; updated plugman reference to 0.19.0 * CB-5913 Fail more gracefully on Windows when symlinks fail.
RE: Plugins Release!
Sounds good to me! From: agri...@chromium.org Date: Tue, 4 Feb 2014 14:35:01 -0500 Subject: Re: Plugins Release! To: dev@cordova.apache.org Sounds good! On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill stevengil...@gmail.com wrote: I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil...@gmail.com wrote: Hey All, What is the general feeling on me moving forward with a plugins release today? I could start the process this afternoon if there aren't any objections or concerns. Are there any plugins that shouldn't be released?
Re: Plugins Release!
Don't do it! I think File still needs some work: https://issues.apache.org/jira/browse/CB-5974 On Tue, Feb 4, 2014 at 3:18 PM, Herm Wong kingoftheo...@hotmail.com wrote: Sounds good to me! From: agri...@chromium.org Date: Tue, 4 Feb 2014 14:35:01 -0500 Subject: Re: Plugins Release! To: dev@cordova.apache.org Sounds good! On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill stevengil...@gmail.com wrote: I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil...@gmail.com wrote: Hey All, What is the general feeling on me moving forward with a plugins release today? I could start the process this afternoon if there aren't any objections or concerns. Are there any plugins that shouldn't be released?
Re: Android/amazon-fireos: web view callbacks
I think both would be fine to add. onCreateWindow is a bit tougher though because you don't know the URL upfront. It'd be hard to multiplex it... we might just say that plugins can register to receive the next call to window.open() though. Did you have any ideas about how this would look? On Tue, Feb 4, 2014 at 3:12 PM, Naik, Archana na...@lab126.com wrote: So for example, onCreateWindow() or onProgressChanged(). We might need to add onCreateWindow() but onProgressChanged() not that urgent. More importantly, we want to let plugins handle there callbacks first and incase they don't we want to fallback on default handlers in these classes. Archana On 2/4/14 11:29 AM, Joe Bowser bows...@gmail.com wrote: Which callbacks in particular are missing? There are some callbacks we don't touch because they can break the WebView. These can include anything that handles gestures (which when done wrong, can break touch events), and other view related callbacks. I'd highly recommend writing tests for the existing behaviour before adding the callbacks, since we've had very bad luck with this in the past w.r.t. the back button. On Tue, Feb 4, 2014 at 11:20 AM, Naik, Archana na...@lab126.com wrote: Hi, Devs There are 2 classes - CordovaWebViewClient and CordovaChromeClient in amazon-fireos repo. They basically handle WebView callbacks. Recently, while using Cordova internally for our projects we needed to handle few more callbacks and noticed they were missing. I was wondering if there is any reason why some callbacks were not handled? If not, I am cool. I would like to add the ones we need for now so want to make sure I am not missing anything. :) Also, one more thing, we would like to pass on these callbacks to plugins incase they want to handle it. If no plugin wants handle it then callback handling will fallback to the default cordova one. Please let me know your thoughts. Thanks Archana
Re: Introducing myself
Welcome Martin! On Tue, Feb 4, 2014 at 4:31 PM, Lorin Beer lorin.beer@gmail.com wrote: Hi Martin, welcome! On Tue, Feb 4, 2014 at 12:52 PM, Brian LeRoux b...@brian.io wrote: Welcome Martin! Glad to have you here and feel free to bug the list for help anytime. =) On Tue, Feb 4, 2014 at 12:42 PM, Martin Gonzalez Glez martin.c.glez.g...@gmail.com wrote: Hi everyone! My name is Martin Gonzalez, I work in the IBM Mobile Foundation, and my job role it's help and contribute with this amazing project that Cordova is. I really want to contribute to the success and development in any way possible. You may already know some folks, that I'm working with (Marcel Kinard, Michael Billau, James Jong, Lisa Deluca). I have good command using Javascript, Java, C/C++, HTML and another languages, however, I don't have much experience with Cordova yet, but I'm really focused on increase my knowledge and expertise. If you have any questions, please feel free to contact me. Thanks. Martin Gonzalez.
Re: Android/amazon-fireos: web view callbacks
I think that both would be fine to add. It's probably a good idea to add these hooks, to be honest, since we don't have any default behaviour associated with them AFAIK. On Tue, Feb 4, 2014 at 3:22 PM, Andrew Grieve agri...@chromium.org wrote: I think both would be fine to add. onCreateWindow is a bit tougher though because you don't know the URL upfront. It'd be hard to multiplex it... we might just say that plugins can register to receive the next call to window.open() though. Did you have any ideas about how this would look? On Tue, Feb 4, 2014 at 3:12 PM, Naik, Archana na...@lab126.com wrote: So for example, onCreateWindow() or onProgressChanged(). We might need to add onCreateWindow() but onProgressChanged() not that urgent. More importantly, we want to let plugins handle there callbacks first and incase they don't we want to fallback on default handlers in these classes. Archana On 2/4/14 11:29 AM, Joe Bowser bows...@gmail.com wrote: Which callbacks in particular are missing? There are some callbacks we don't touch because they can break the WebView. These can include anything that handles gestures (which when done wrong, can break touch events), and other view related callbacks. I'd highly recommend writing tests for the existing behaviour before adding the callbacks, since we've had very bad luck with this in the past w.r.t. the back button. On Tue, Feb 4, 2014 at 11:20 AM, Naik, Archana na...@lab126.com wrote: Hi, Devs There are 2 classes - CordovaWebViewClient and CordovaChromeClient in amazon-fireos repo. They basically handle WebView callbacks. Recently, while using Cordova internally for our projects we needed to handle few more callbacks and noticed they were missing. I was wondering if there is any reason why some callbacks were not handled? If not, I am cool. I would like to add the ones we need for now so want to make sure I am not missing anything. :) Also, one more thing, we would like to pass on these callbacks to plugins incase they want to handle it. If no plugin wants handle it then callback handling will fallback to the default cordova one. Please let me know your thoughts. Thanks Archana
CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On Tue, Feb 4, 2014 at 6:20 PM, Joe Bowser bows...@gmail.com wrote: Don't do it! I think File still needs some work: https://issues.apache.org/jira/browse/CB-5974 It's too early yet to tell whether this has become a problem, but obviously this is something that people are going to run into (and are already running into [1]) Background: Because of CB-5915 [2] (and it's android sister, CB-5916 [3]), developers who upgrade File will find that their applications crash with a log message the first time they use any of the File API. (I'd crash sooner, but File is not currently a load-on-startup sort of plugin) There was a lot of discussion about this on the list [4], and I thought that we had reached consensus, but maybe it needs one more hard look. The Problem: The log message hopefully tells them what they need to do to fix the problem, but many (most?) devs aren't going to see it; they're only going to see that their app is broken now, and come to us (hopefully) or StackOverflow (more likely) to figure out why and what to do about it. They will probably be loud, we will probably be blamed for their apps breaking (no matter how simple the fix is,) and it will probably be a bad time for everybody. It's unfortunate that we feel we have to do this; there just doesn't seem to be any other way to encourage developers to use anything but the old locations for persistent files. On Android this is the root-of-the-sdcard-even-if-its-just-a-partition-shared-by-all-apps location. On iOS, its the Documents directory, although Library makes far more sense for these sort of files. If we added a default value, the only possible default we could use is Compatibility, which means that approximately 100% of new apps will ship with that default. We *can't* use the new location as the default, because that will cause real pain for the users, not the devs. Real users will lose access to real data, and that worries me much more than a mob of angry devs with pitchforks. Options: 1. Go big or go home: Make it crash harder. I was already going to add a paragraph to the plugin.xml file to be shown on install, but we *could* make the app break on launch, rather than on the first use of File. We could force File to load on startup, or we could make Javascript alert() the dev on startup (something like please fix config.xml and then delete this line), or we could break the plugin encapsulation and make ConfigParser check for this special case. Maybe we could go even further and find a way to make it break on build. At least then apps wouldn't make it to the store broken. 2. Leave it the way it is. Brace for the angry mob with blog posts, release notes, install guides, READMEs, vigilance on StackOverfow, and hope that it's enough. 3. Put in the safe default and live with it. Accept that every single Cordova app is going to use the default and that their file storage roots will suck. By the time you've educated a developer, chances are their apps have already been released and have users with stored data. Work hard on a migration utility/plugin and make sure that it can never possibly lose data. With my Google hat[5] on, I don't mind #3 -- we've ensured that the apps created with our framework use the new defaults, since they're all new apps by definition. Wearing my Apache hat, though, I don't think it's best for Cordova in the long term. At some point, I think we should rip off the bandaid. If we don't do it now, with a major rev bump of File, then we're just postponing the hurt. There may be other options; lets try to get consensus on this before pulling the trigger. [1] https://issues.apache.org/jira/browse/CB-5899 [2] https://issues.apache.org/jira/browse/CB-5915 [3] https://issues.apache.org/jira/browse/CB-5916 [4] http://markmail.org/message/tzcljj3xgycbkx3g [5] http://www.flickr.com/photos/nooks/6858535568/ On Tue, Feb 4, 2014 at 3:18 PM, Herm Wong kingoftheo...@hotmail.com wrote: Sounds good to me! From: agri...@chromium.org Date: Tue, 4 Feb 2014 14:35:01 -0500 Subject: Re: Plugins Release! To: dev@cordova.apache.org Sounds good! On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill stevengil...@gmail.com wrote: I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil...@gmail.com wrote: Hey All, What is the general feeling on me moving forward with a plugins release today? I could start the process this afternoon if there aren't any objections or concerns. Are there any plugins that shouldn't be released?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
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?
