incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Wallis <>
Subject Re: Consistent implementation of the whitelist
Date Tue, 31 Jan 2012 22:13:34 GMT
For more information on how WebWorks implemented the widget config.xml
spec, and the additions to it we made with the rim: namespace, please see:

I would certainly support a single config file to rule them all with
platform specific artifacts created at build time. ;)

As you can see from our implementation, we tried to be true to the config
spec, and only added to it.  That said, at this point, we are really only
tied to it from a compatibility perspective for our existing devs. As
Laurent mentioned, we don't really have a stake in trying to promote the

Ken Wallis
Product Manager ­ BlackBerry WebWorks

Research In Motion
(905) 629-4746 x14369

-----Original Message-----
From: Filip Maj <>
Reply-To: <>
Date: Tue, 31 Jan 2012 13:54:16 -0800
To: "" <>
Subject: Re: Consistent implementation of the whitelist

>On 12-01-31 1:46 PM, "Shazron" <> wrote:
>>>* for most platforms, config.xml does not map to a single file. On
>>>for example, AndroidManifest.xml, strings.xml and phonegap.xml are all
>>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.

This transmission (including any attachments) may contain confidential information, privileged
material (including material protected by the solicitor-client or other applicable privileges),
or constitute non-public information. Any use of this information by anyone other than the
intended recipient is prohibited. If you have received this transmission in error, please
immediately reply to the sender and delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended recipients is not authorized
and may be unlawful.

View raw message