Murat Sutunc wrote: >I think we have a couple of options here: > >Option 1 - Adding --list as an optional parameter to cordova run >List is related to run and there’s not that much need to introduce >another top level command for this . Considering all the previous >discussions we had I can see two potential implementations for this: > A) look at the parameters of run call in platform level >and take action > B) look at the parameters of run call in lib level and >take action >Option 1.A results in errors or unexpected behavior on platforms that do >not support --list (including older versions).
This is clearly a no-go >Option 1.B involves parsing arguments in >cordova-lib\cordova-lib\src\cordova\run.js (along with the cli). This isn't my preference for where in cordova-lib the code lives > From this point instead of calling >project_root/platforms/<platform>/cordova/run we can call >project_root/platforms/<platform>/cordova/lib/list-* and so on. >From a how the code has to work, this is how it has to work. >Option 2 - Adding ‘list’ as an optional parameter to a new command. >List can be put under a new top level command such as target. This design >involves adding a new top level command and corresponding handler in >cordova-lib. Similar to run, the code with logic will reside somewhere >like cordova-lib\cordova-lib\src\cordova\target.js. > >I would like to get some feedback about these options. I'd prefer option 2. At the very least, if you're going to do option 1.b, please make sure that list is a function which is independently reachable via the api so that js callers can easily get the list of devices for platform[s], and can determine if the feature is available (by checking for the presence of the api function).
smime.p7s
Description: S/MIME cryptographic signature
