Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of curtis.bryce@gmail.com
 designates 209.85.214.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <1106599726-1328050030-cardhu_decombobulator_blackberry.rim.net-1580858648-@b1.c19.bise6.blackberry>
References: 
 <CAE6O_-YfC-3=9ZtEakXOUqgPB+8WKRyCU0cSvMwK7ccfZp5imw@mail.gmail.com>
	<CB4DA1E3.3B8E%fil@adobe.com>
	<1106599726-1328050030-cardhu_decombobulator_blackberry.rim.net-1580858648-@b1.c19.bise6.blackberry>
Date: Tue, 31 Jan 2012 17:00:24 -0600
Message-ID: 
 <CAMT1KGMtqrDzUARvnQiFqm1DxjiJMif_CLVEaQrMTiHOX9yOkw@mail.gmail.com>
Subject: Re: Consistent implementation of the whitelist
From: Bryce Curtis <curtis.bryce@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0015175cbabaa0d69404b7daed92

--0015175cbabaa0d69404b7daed92
Content-Type: text/plain; charset=ISO-8859-1

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, <gtanner@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 <fil@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" <shazron@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.
>
>

--0015175cbabaa0d69404b7daed92--