incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryce Curtis <>
Subject Re: Consistent implementation of the whitelist
Date Tue, 31 Jan 2012 23:00:24 GMT
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

On Tue, Jan 31, 2012 at 4:47 PM, <> 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 <>
> Date: Tue, 31 Jan 2012 13:54:16
> To:<>
> Reply-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
> >>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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message