..taking a look at the cli create.js script, we would need to update it a bit to actually have it import a hello-world config.xml. The lib actually ships the template config.xml right now instead of the hello-world project, which seems unnecessary given our --copy-from/--link-to import logic. Seems we could simplify the whole thing.
-Michal On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny <mmo...@chromium.org> wrote: > My thoughts: > > - The split between <allow-navigation>, <allow-intent>, and <access>: Like > it a lot. > - I think the defaults *for the plugin* are very reasonable. However, we > may want to provide a default set of tags for the hello world app. A year > or so ago we added a default access * whitelist and I think maybe we should > continue that. (on the other hand, I've gotten used to explicitly > whitelisting every url as part of chrome packaged app development and its > not so bad). > - Additionally, that means this plugin should be installed by default. > As we discussed this morning, with the new plugin --save functionality we > could just add this to the helloworld config.xml, I think! > - Do you really need a CSP meta tag *and* <access> declarations? Thats > what the README.md implies, but I would assume CSP trumps? > > -Michal > > On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve <agri...@chromium.org> > wrote: > >> I've tried to explain it in the plugin's readme: >> >> https://github.com/apache/cordova-plugins/tree/master/url-policy >> >> Some points for discussion: >> - What should the default behaviour be for the three whitelists (what >> should happen if not whitelist plugin is installed). >> - right now it can't open external URLs >> - and can't do XHRs to http(s) >> - Is the plugin name decent ("url-policy"). We should make a dedicated git >> repo for it (as well as for legacy-whitelist plugin) >> > >
