I would also vote for leaning more towards the config.xml for whitelisting.
I know I didn't even know about plugins.xml and its purpose until I had been working on android for a week or so. I may have been biased by coming from BlackBerry first and expecting it to use my values from the config.xml Sent on the TELUS Mobility network with BlackBerry -----Original Message----- From: Filip Maj <f...@adobe.com> Date: Tue, 31 Jan 2012 13:54:16 To: callback-dev@incubator.apache.org<callback-dev@incubator.apache.org> Reply-To: callback-dev@incubator.apache.org Subject: Re: Consistent implementation of the whitelist On 12-01-31 1:46 PM, "Shazron" <shaz...@gmail.com> wrote: >>* for most platforms, config.xml does not map to a single file. On >>Android, >>for example, AndroidManifest.xml, strings.xml and phonegap.xml are all >>involved; > >Not sure what you mean about Android - the three .xml files are >compiled into a config.xml? Other way around. A config.xml file would, at build-time, be parsed and compiled into however many native documents a platform needs. In Android's case, a AndroidManifest.xml, strings.xml, etc. iOS would do the same but compile into the app .plist file and whatever other files iOS use. If you want specifics, take a look at Andrew's confetti project and what it does to parse config.xml into app.plist or whatever. > >Where would plugins.xml fit in with config.xml? Plugins.xml creates a simple name to native class mapping for the various cordova APIs. Specifying an API in plugins.xml makes it available to the app. The native-webview bridge method (exec) calls the label/name associated to the class it wants to access. To replace plugins.xml with a config.xml,we can use the <feature> element. It's a direct one-to-one mapping. Vanilla BlackBerry WebWorks apps already use this approach to define which blackberry WebWorks JS APIs you want access to in the application.
