You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Bryce Curtis <cu...@gmail.com> on 2012/02/01 00:00:24 UTC
Re: Consistent implementation of the whitelist
Having a single file like config.xml is desirable. I don't know how big it
ends up being to support all of the individual platform options - icons,
plugin mappings, etc., and how expensive it is to parse this file at
runtime before plugins can be loaded and inited. The app startup time is
directly affected by the time it takes to load and run plugins like Device
and Connection. At the least, it can be used at build time to gen one or
more runtime files - either due to platform requirements or for
optimizations.
On Tue, Jan 31, 2012 at 4:47 PM, <gt...@gmail.com> wrote:
> 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 <fi...@adobe.com>
> Date: Tue, 31 Jan 2012 13:54:16
> To: callback-dev@incubator.apache.org<ca...@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" <sh...@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.
>
>
RE: Consistent implementation of the whitelist
Posted by Laurent Hasson <lh...@rim.com>.
One thing we do with Webworks is that as part of our build process, we "compile" config.xml into a runtime config.json artifact that plugs right into our runtime code.
So, to Brian's point earlier I think, config.xml is really UI for the developer. But I'd add that specifying the actual runtime artifact also makes sense. Assuming that somehow the xml file is parsed at runtime is a bit much I think.
Thank You
------------------------------------------------
- LDH (Laurent Hasson) -
- Technical Director, BlackBerry Web Platform -
- Research In Motion -
- Email: lhasson@rim.com -
- Mobile: 646-460-7066 -
- Twitter: @ldhasson
------------------------------------------------
"Ha ha ha... He doesn't know how to use the three seashells!" - Erwin
-----Original Message-----
From: Bryce Curtis [mailto:curtis.bryce@gmail.com]
Sent: Tuesday, January 31, 2012 6:00 PM
To: callback-dev@incubator.apache.org
Subject: Re: Consistent implementation of the whitelist
Having a single file like config.xml is desirable. I don't know how big it
ends up being to support all of the individual platform options - icons,
plugin mappings, etc., and how expensive it is to parse this file at
runtime before plugins can be loaded and inited. The app startup time is
directly affected by the time it takes to load and run plugins like Device
and Connection. At the least, it can be used at build time to gen one or
more runtime files - either due to platform requirements or for
optimizations.
On Tue, Jan 31, 2012 at 4:47 PM, <gt...@gmail.com> wrote:
> 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 <fi...@adobe.com>
> Date: Tue, 31 Jan 2012 13:54:16
> To: callback-dev@incubator.apache.org<ca...@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" <sh...@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.
>
>
---------------------------------------------------------------------
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.