The feedback is definitely very valuable. I was trying to understand the issues with the existing design and once the impact is realized all the commits are immediately reversed. I'm currently looking into your suggestions and will try to come up with a better design.
-----Original Message----- From: Josh Soref [mailto:jso...@blackberry.com] Sent: Tuesday, January 6, 2015 10:40 AM To: dev@cordova.apache.org Subject: Re: Cordova --list option implementation Parashuram wrote: >Josh, is your concern that ‹list throws an error in case of blackberry? No. my concern is that the way this was done was wrong <PERIOD>. It doesn't work for *ANY* project that exists today with *ANY* platform. Cordova's design is to be backwards compatible. The code that was written absolutely failed that. I tried to hint at that in my review comments. But that was totally ignored. Note that list threw an error in android (@released) too (as Andrew belatedly noted). >We could fix that by either >1a- Ignoring unknown flags like other platforms - and document the >ignoring part as the default behavior This is too late. You can't really change the behavior because cordova-cli/cordova-lib needs to support old projects with old platforms. >1b - or change other platforms to throw error on unsupported flags. In >this case, ‹list would do the check to see if ‹list is implemented first. You can't do this for the same reason that we can't do 1a. >2. Implement ‹list for blackberry, thereby not having error on any >platform. We could then have a separate discussion about what happens when >a flag is not supported by a platform. It's not specific to blackberry10, it applies to all existing platforms which happen to have the underlying support but which shipped without an imaginary change to run.js >It would be great if we can let users use the ‹list functionality with >minimal disruption to any platform. Correct. And this is trivially done -- put the code into cordova-lib and have it run the scripts from the platforms, instead of requiring changes to platforms — they already did the work they need to do (they are free to replace their existing impls w/ node.js impls if they haven't already, but that's transparent to cordova-lib).
