You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2012/01/31 03:04:43 UTC
Consistent implementation of the whitelist
During the 1.4.0 planning call, Anis proposed these requirements:
1. a consistent implementation of the whitelist across all platforms
2. follow the Opera standard (need a url to the docs for this,
couldn't find it using the obvious keywords)
3. white-listing should be documented on the docs site (Getting
Started section)
I like the Opera standard (see Android implementation here for an
example: https://github.com/apache/incubator-cordova-android/blob/master/framework/res/xml/phonegap.xml).
The only problem with iOS adopting this is the .plist format does not
allow attributes in its xml. Right now the list of allowed hosts is
just an array of strings, but to support "attributes" it would have to
be an array of dictionaries. I could make this change but this
satisfies neither requirements (1) nor (2).
Changing the iOS implementation to support a PhoneGap.xml list instead
of .plist is another effort entirely, but better now than later -
unless we are going to use config.xml. Thoughts?
Re: Consistent implementation of the whitelist
Posted by Filip Maj <fi...@adobe.com>.
Here is the w3c one: http://www.w3.org/TR/widgets/ it covers 95% of cases
Here is how PhoneGap Build employs config.xml:
https://build.phonegap.com/docs/config-xml
The phonegap build docs are an excellent starting point, I think.
On 12-01-31 12:33 PM, "Laurent Hasson" <lh...@rim.com> wrote:
>One configuration file to rule them all... Is the idea to still remain
>"as faithful as possible" to the Widget's config.xml spec, or are we now
>taking more liberties? I think that spec is pretty much done, and
>wondering if there is any other implementation out there. More pointedly,
>where is the spec for our config.xml?
>
>
>
>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: Patrick Mueller [mailto:pmuellr@gmail.com]
>Sent: Tuesday, January 31, 2012 3:31 PM
>To: callback-dev@incubator.apache.org
>Subject: Re: Consistent implementation of the whitelist
>
>On Tue, Jan 31, 2012 at 15:21, Shazron <sh...@gmail.com> wrote:
>
>> So let's all agree on the structure of the plugins and whitelist in
>> config.xml (if we all decide to go this route that is).
>>
>
>sounds good! What XML parsers do people use w/node.js?
>
>
>> We could modify the iOS Info.plist during build time, yes - by running
>> a script post-build (this is part of a project's Build Phase).
>
>
>As much as is possible/reasonable, I'd love to head in this direction -
>build out platform-specific stuff (iOS .plist's) based on the One True
>Configuration FileT during "build" stages.
>
>--
>Patrick Mueller
>http://muellerware.org
>
>---------------------------------------------------------------------
>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.
Re: Consistent implementation of the whitelist
Posted by Brian LeRoux <b...@brian.io>.
This is precisely why I was using Python in a bunch of disconnected
shell scripts in the orig Cordova prototype work. Agree however that
using Node would be a preferable tool for the job overall. A Python
shim for the bits that it cannot do is completely pragmatic.
On Wed, Feb 1, 2012 at 6:21 AM, Patrick Mueller <pm...@gmail.com> wrote:
> On Tue, Jan 31, 2012 at 15:42, Andrew Lunny <al...@gmail.com> wrote:
>
>> * @pmuellr: there is no good pure JS XML parser in Node; there are bindings
>> to libxml2, but we can't reasonably expect end-users to have the external
>> dependencies for that. I have been using -
>> https://github.com/racker/node-elementtree - but it lacks some features -
>> notably support for namespaces and the concept of a document (which affects
>> absolute XPath selectors)
>
>
> I could care less about XPath, but support for namespaces is presumably
> required to be able to successfully parse android XML files, right? I
> assume there will be a need to do that, in the tooling, somewhere.
>
> The reason I asked about XML parsers for node, if it wasn't obvious, is
> that I'd like to see the tooling implemented on node (and CoffeeScript :-).
> But I'm not married to it. Python would be my next choice - it's widely
> available on all of the desktop platforms we would support the tooling on.
> WebKit has traditionally done all their tooling in Perl, but over the last
> few years, mainly due to the Googlites, the tooling is migrating to Python.
> The only issue that comes up is having to support old versions of Python
> for ancient versions of Mac OS X.
>
> Another alternative would be to write most of the tooling in node, and do
> the XML parsing with a single Python script, whose sole purpose in life
> would be to read XML and spit out a stream of DOM nodes (or something).
> Eventually there's got to be an XML parser for node, right? RIGHT?
>
> Another conclusion re: node not supporting XML might be: we shouldn't be
> using XML for our configuration files. JSON isn't a great alternative,
> since it's neither human readable or writable. Or maybe something like
> this json tool helps [1]. CoffeeScript Object Notation [2] would probably
> be workable. YAML maybe.
>
> [1] https://github.com/trentm/json
> [2] https://github.com/balupton/cson.npm
>
> --
> Patrick Mueller
> http://muellerware.org
Re: Consistent implementation of the whitelist
Posted by Patrick Mueller <pm...@gmail.com>.
On Tue, Jan 31, 2012 at 15:42, Andrew Lunny <al...@gmail.com> wrote:
> * @pmuellr: there is no good pure JS XML parser in Node; there are bindings
> to libxml2, but we can't reasonably expect end-users to have the external
> dependencies for that. I have been using -
> https://github.com/racker/node-elementtree - but it lacks some features -
> notably support for namespaces and the concept of a document (which affects
> absolute XPath selectors)
I could care less about XPath, but support for namespaces is presumably
required to be able to successfully parse android XML files, right? I
assume there will be a need to do that, in the tooling, somewhere.
The reason I asked about XML parsers for node, if it wasn't obvious, is
that I'd like to see the tooling implemented on node (and CoffeeScript :-).
But I'm not married to it. Python would be my next choice - it's widely
available on all of the desktop platforms we would support the tooling on.
WebKit has traditionally done all their tooling in Perl, but over the last
few years, mainly due to the Googlites, the tooling is migrating to Python.
The only issue that comes up is having to support old versions of Python
for ancient versions of Mac OS X.
Another alternative would be to write most of the tooling in node, and do
the XML parsing with a single Python script, whose sole purpose in life
would be to read XML and spit out a stream of DOM nodes (or something).
Eventually there's got to be an XML parser for node, right? RIGHT?
Another conclusion re: node not supporting XML might be: we shouldn't be
using XML for our configuration files. JSON isn't a great alternative,
since it's neither human readable or writable. Or maybe something like
this json tool helps [1]. CoffeeScript Object Notation [2] would probably
be workable. YAML maybe.
[1] https://github.com/trentm/json
[2] https://github.com/balupton/cson.npm
--
Patrick Mueller
http://muellerware.org
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.
Re: Consistent implementation of the whitelist
Posted by Bryce Curtis <cu...@gmail.com>.
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 gt...@gmail.com.
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 Filip Maj <fi...@adobe.com>.
Sounds good.
I would aim for 1.6 as well. On that topic, we should start a thread about
1.5 targets :)
On 12-01-31 2:10 PM, "Shazron" <sh...@gmail.com> wrote:
>Thanks Fil.
>
>I think this is what I would plan for iOS:
>
>1. Convert PhoneGap.plist settings into config.xml settings
>(whitelist, plugins, other features)
>2. Change Objective-C code to read from config.xml
>3. Add config.xml to the Xcode template
>4. Add post-build phase to the Xcode template to read config.xml
>settings and write them into the Info.plist (possibly using Andrew's
>confetti)
>4. Write upgrade steps for PhoneGap.plist --> config.xml in the
>Upgrade Guide doc
>
>Would we target this1.5 or later? We don't have to do it all at the
>same time. I would propose it to be in 1.6 for all platform support,
>so 1.5 we can have interim support in some platforms. I haven't
>consulted the backlog of tasks for the product roadmap
>
>
>On Tue, Jan 31, 2012 at 1:54 PM, Filip Maj <fi...@adobe.com> wrote:
>> 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 Shazron <sh...@gmail.com>.
Thanks Fil.
I think this is what I would plan for iOS:
1. Convert PhoneGap.plist settings into config.xml settings
(whitelist, plugins, other features)
2. Change Objective-C code to read from config.xml
3. Add config.xml to the Xcode template
4. Add post-build phase to the Xcode template to read config.xml
settings and write them into the Info.plist (possibly using Andrew's
confetti)
4. Write upgrade steps for PhoneGap.plist --> config.xml in the
Upgrade Guide doc
Would we target this1.5 or later? We don't have to do it all at the
same time. I would propose it to be in 1.6 for all platform support,
so 1.5 we can have interim support in some platforms. I haven't
consulted the backlog of tasks for the product roadmap
On Tue, Jan 31, 2012 at 1:54 PM, Filip Maj <fi...@adobe.com> wrote:
> 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 Ken Wallis <kw...@rim.com>.
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:
http://developer.blackberry.com/html5/documentation/ww_developing/working_w
ith_config_xml_file_1866970_11.html
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
spec.
--
Ken Wallis
Product Manager BlackBerry WebWorks
Research In Motion
(905) 629-4746 x14369
-----Original Message-----
From: Filip Maj <fi...@adobe.com>
Reply-To: <ca...@incubator.apache.org>
Date: Tue, 31 Jan 2012 13:54:16 -0800
To: "callback-dev@incubator.apache.org" <ca...@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.
Re: Consistent implementation of the whitelist
Posted by Filip Maj <fi...@adobe.com>.
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 Shazron <sh...@gmail.com>.
> * 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?
Where would plugins.xml fit in with config.xml?
Re: Consistent implementation of the whitelist
Posted by Andrew Lunny <al...@gmail.com>.
+1 on protoyping/experimenting config.xml support
A couple things to note:
* 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; on iOS, App-Info.plist, PhoneGap.plist and (for some preferences)
the xcodeproj itself are modified. But getting something prototyped would
allow these challenges to become clearer.
* the WebWorks SDK has some rim specific extensions, as the PhoneGap Build
style has some PhoneGap specific extensions (the splash element Fil
mentioned, for example). It's important to make sure these play nicely
together (hopefully XML namespaces are sufficient for this)
* @pmuellr: there is no good pure JS XML parser in Node; there are bindings
to libxml2, but we can't reasonably expect end-users to have the external
dependencies for that. I have been using -
https://github.com/racker/node-elementtree - but it lacks some features -
notably support for namespaces and the concept of a document (which affects
absolute XPath selectors)
On 31 January 2012 12:33, Laurent Hasson <lh...@rim.com> wrote:
> One configuration file to rule them all... Is the idea to still remain "as
> faithful as possible" to the Widget's config.xml spec, or are we now taking
> more liberties? I think that spec is pretty much done, and wondering if
> there is any other implementation out there. More pointedly, where is the
> spec for our config.xml?
>
>
>
> 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: Patrick Mueller [mailto:pmuellr@gmail.com]
> Sent: Tuesday, January 31, 2012 3:31 PM
> To: callback-dev@incubator.apache.org
> Subject: Re: Consistent implementation of the whitelist
>
> On Tue, Jan 31, 2012 at 15:21, Shazron <sh...@gmail.com> wrote:
>
> > So let's all agree on the structure of the plugins and whitelist in
> > config.xml (if we all decide to go this route that is).
> >
>
> sounds good! What XML parsers do people use w/node.js?
>
>
> > We could modify the iOS Info.plist during build time, yes - by running
> > a script post-build (this is part of a project's Build Phase).
>
>
> As much as is possible/reasonable, I'd love to head in this direction -
> build out platform-specific stuff (iOS .plist's) based on the One True
> Configuration FileT during "build" stages.
>
> --
> Patrick Mueller
> http://muellerware.org
>
> ---------------------------------------------------------------------
> 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.
>
RE: Consistent implementation of the whitelist
Posted by Laurent Hasson <lh...@rim.com>.
One configuration file to rule them all... Is the idea to still remain "as faithful as possible" to the Widget's config.xml spec, or are we now taking more liberties? I think that spec is pretty much done, and wondering if there is any other implementation out there. More pointedly, where is the spec for our config.xml?
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: Patrick Mueller [mailto:pmuellr@gmail.com]
Sent: Tuesday, January 31, 2012 3:31 PM
To: callback-dev@incubator.apache.org
Subject: Re: Consistent implementation of the whitelist
On Tue, Jan 31, 2012 at 15:21, Shazron <sh...@gmail.com> wrote:
> So let's all agree on the structure of the plugins and whitelist in
> config.xml (if we all decide to go this route that is).
>
sounds good! What XML parsers do people use w/node.js?
> We could modify the iOS Info.plist during build time, yes - by running
> a script post-build (this is part of a project's Build Phase).
As much as is possible/reasonable, I'd love to head in this direction -
build out platform-specific stuff (iOS .plist's) based on the One True
Configuration FileT during "build" stages.
--
Patrick Mueller
http://muellerware.org
---------------------------------------------------------------------
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.
Re: Consistent implementation of the whitelist
Posted by Patrick Mueller <pm...@gmail.com>.
On Tue, Jan 31, 2012 at 15:21, Shazron <sh...@gmail.com> wrote:
> So let's all agree on the structure of the plugins and whitelist in
> config.xml (if we all decide to go this route that is).
>
sounds good! What XML parsers do people use w/node.js?
> We could modify the iOS Info.plist during build time, yes - by running
> a script post-build (this is part of a project's Build Phase).
As much as is possible/reasonable, I'd love to head in this direction -
build out platform-specific stuff (iOS .plist's) based on the One True
Configuration File™ during "build" stages.
--
Patrick Mueller
http://muellerware.org
Re: Consistent implementation of the whitelist
Posted by Shazron <sh...@gmail.com>.
So let's all agree on the structure of the plugins and whitelist in
config.xml (if we all decide to go this route that is).
We could modify the iOS Info.plist during build time, yes - by running
a script post-build (this is part of a project's Build Phase).
On Tue, Jan 31, 2012 at 12:02 PM, Anis KADRI <an...@gmail.com> wrote:
> Yeah I think everything should be merged in a config.xml. Right now
> Android has a phonegap.xml and a plugins.xml but they should both be
> in a config.xml. At least, that is my understanding.
> Why don't we create a config.xml for iOS as well that would get
> converted to an info.plist at build time (should be possible no ?).
>
> On Tue, Jan 31, 2012 at 11:49 AM, Filip Maj <fi...@adobe.com> wrote:
>> Config.xml is an excellent abstraction on top of all platforms' specifics.
>>
>> At build time we could have some tooling around parsing a config.xml into
>> each platform's required formats (plist, xml, whatevs).
>>
>> Andrew already has a great tool that does exactly this:
>> https://github.com/alunny/confetti
>>
>> On 12-01-31 11:45 AM, "Shazron" <sh...@gmail.com> wrote:
>>
>>>I'd rather wait until we all agree on supporting one .xml config
>>>rather than having interim changes (less friction for users
>>>upgrading).
>>>
>>>What about plugins? I see that android uses a plugins.xml
>>>
>>>As for icons and splash screens, unfortunately on iOS it has to be
>>>specified in the app's Info.plist and cannot be from an external
>>>source, since this is handled by the app itself and outside of our
>>>control.
>>>
>>>On Tue, Jan 31, 2012 at 11:38 AM, Filip Maj <fi...@adobe.com> wrote:
>>>> I think a spec that is way more pertinent to Cordova for solving this
>>>> problem (and also many others) is the config.xml spec. Anis pointed out
>>>> the <access> element. WebWorks already uses a config.xml file as a base
>>>> for defining application metadata and configuration. So does PhoneGap
>>>> Build. Tons of goodies in there that we can use on top of caching and
>>>> server whitelisting, such as:
>>>>
>>>> - icon definitions (<icon> element)
>>>> - generic preference/configuration elements (<preference>). I believe
>>>> phonegap build uses this for things such as locking orientation in an
>>>>app.
>>>> Basically anything in phonegap.xml can be mapped to <preference>
>>>>elements.
>>>> - <feature> element. *VERY* pertinent to defining which APIs you want
>>>>your
>>>> app to access. Essentially could replace plugins.xml in cordova
>>>>currently.
>>>> - <author>, <title>, <license>, <description> elements...
>>>> - free localization of strings (such as titles) as well as content by
>>>> piggybacking on xml:lang attributes for different elements.
>>>> - application entry point (entry page) definitions (<content>)
>>>> - finally, there is a <param> element that is a key:value pair. We could
>>>> map anything to this...
>>>>
>>>> PhoneGap Build extended the config.xml elements with a splash screen
>>>> (<splash>) element as well.
>>>>
>>>>
>>>> The possibilities are endless, and we have a pretty complete spec. Also
>>>> for icing on the cake, Michael Brooks and I are involved with the W3C
>>>> community group related to the widget spec so we already have ins to
>>>> present feedback and iterate on the spec if necessary.
>>>>
>>
Re: Consistent implementation of the whitelist
Posted by Anis KADRI <an...@gmail.com>.
Yeah I think everything should be merged in a config.xml. Right now
Android has a phonegap.xml and a plugins.xml but they should both be
in a config.xml. At least, that is my understanding.
Why don't we create a config.xml for iOS as well that would get
converted to an info.plist at build time (should be possible no ?).
On Tue, Jan 31, 2012 at 11:49 AM, Filip Maj <fi...@adobe.com> wrote:
> Config.xml is an excellent abstraction on top of all platforms' specifics.
>
> At build time we could have some tooling around parsing a config.xml into
> each platform's required formats (plist, xml, whatevs).
>
> Andrew already has a great tool that does exactly this:
> https://github.com/alunny/confetti
>
> On 12-01-31 11:45 AM, "Shazron" <sh...@gmail.com> wrote:
>
>>I'd rather wait until we all agree on supporting one .xml config
>>rather than having interim changes (less friction for users
>>upgrading).
>>
>>What about plugins? I see that android uses a plugins.xml
>>
>>As for icons and splash screens, unfortunately on iOS it has to be
>>specified in the app's Info.plist and cannot be from an external
>>source, since this is handled by the app itself and outside of our
>>control.
>>
>>On Tue, Jan 31, 2012 at 11:38 AM, Filip Maj <fi...@adobe.com> wrote:
>>> I think a spec that is way more pertinent to Cordova for solving this
>>> problem (and also many others) is the config.xml spec. Anis pointed out
>>> the <access> element. WebWorks already uses a config.xml file as a base
>>> for defining application metadata and configuration. So does PhoneGap
>>> Build. Tons of goodies in there that we can use on top of caching and
>>> server whitelisting, such as:
>>>
>>> - icon definitions (<icon> element)
>>> - generic preference/configuration elements (<preference>). I believe
>>> phonegap build uses this for things such as locking orientation in an
>>>app.
>>> Basically anything in phonegap.xml can be mapped to <preference>
>>>elements.
>>> - <feature> element. *VERY* pertinent to defining which APIs you want
>>>your
>>> app to access. Essentially could replace plugins.xml in cordova
>>>currently.
>>> - <author>, <title>, <license>, <description> elements...
>>> - free localization of strings (such as titles) as well as content by
>>> piggybacking on xml:lang attributes for different elements.
>>> - application entry point (entry page) definitions (<content>)
>>> - finally, there is a <param> element that is a key:value pair. We could
>>> map anything to this...
>>>
>>> PhoneGap Build extended the config.xml elements with a splash screen
>>> (<splash>) element as well.
>>>
>>>
>>> The possibilities are endless, and we have a pretty complete spec. Also
>>> for icing on the cake, Michael Brooks and I are involved with the W3C
>>> community group related to the widget spec so we already have ins to
>>> present feedback and iterate on the spec if necessary.
>>>
>
Re: Consistent implementation of the whitelist
Posted by Brian LeRoux <b...@brian.io>.
Well, Fil does bring up a good point about having one file to rule
them all but I see phonegap.xml and plugins.xml as platform
implementation details and config.xml as a part of the user space.
Imagine, the following, ideal-in-brians-mind project:
/app
|-plugins/
|-native/
| |-ios/
| '-android/
'-www/
|-index.html
'-config.xml
The cordova user *really* shouldn't care about what happens in those
native folders. Fils route would make the build a simply copy>paste of
the config.xml and likley a whole lot less likely to be error prone in
transformations.
Again, fuck it shaz, start a branch and get prototyping. Either path
is not technically challenging.
On Tue, Jan 31, 2012 at 11:49 AM, Filip Maj <fi...@adobe.com> wrote:
> Config.xml is an excellent abstraction on top of all platforms' specifics.
>
> At build time we could have some tooling around parsing a config.xml into
> each platform's required formats (plist, xml, whatevs).
>
> Andrew already has a great tool that does exactly this:
> https://github.com/alunny/confetti
>
> On 12-01-31 11:45 AM, "Shazron" <sh...@gmail.com> wrote:
>
>>I'd rather wait until we all agree on supporting one .xml config
>>rather than having interim changes (less friction for users
>>upgrading).
>>
>>What about plugins? I see that android uses a plugins.xml
>>
>>As for icons and splash screens, unfortunately on iOS it has to be
>>specified in the app's Info.plist and cannot be from an external
>>source, since this is handled by the app itself and outside of our
>>control.
>>
>>On Tue, Jan 31, 2012 at 11:38 AM, Filip Maj <fi...@adobe.com> wrote:
>>> I think a spec that is way more pertinent to Cordova for solving this
>>> problem (and also many others) is the config.xml spec. Anis pointed out
>>> the <access> element. WebWorks already uses a config.xml file as a base
>>> for defining application metadata and configuration. So does PhoneGap
>>> Build. Tons of goodies in there that we can use on top of caching and
>>> server whitelisting, such as:
>>>
>>> - icon definitions (<icon> element)
>>> - generic preference/configuration elements (<preference>). I believe
>>> phonegap build uses this for things such as locking orientation in an
>>>app.
>>> Basically anything in phonegap.xml can be mapped to <preference>
>>>elements.
>>> - <feature> element. *VERY* pertinent to defining which APIs you want
>>>your
>>> app to access. Essentially could replace plugins.xml in cordova
>>>currently.
>>> - <author>, <title>, <license>, <description> elements...
>>> - free localization of strings (such as titles) as well as content by
>>> piggybacking on xml:lang attributes for different elements.
>>> - application entry point (entry page) definitions (<content>)
>>> - finally, there is a <param> element that is a key:value pair. We could
>>> map anything to this...
>>>
>>> PhoneGap Build extended the config.xml elements with a splash screen
>>> (<splash>) element as well.
>>>
>>>
>>> The possibilities are endless, and we have a pretty complete spec. Also
>>> for icing on the cake, Michael Brooks and I are involved with the W3C
>>> community group related to the widget spec so we already have ins to
>>> present feedback and iterate on the spec if necessary.
>>>
>
Re: Consistent implementation of the whitelist
Posted by Filip Maj <fi...@adobe.com>.
Config.xml is an excellent abstraction on top of all platforms' specifics.
At build time we could have some tooling around parsing a config.xml into
each platform's required formats (plist, xml, whatevs).
Andrew already has a great tool that does exactly this:
https://github.com/alunny/confetti
On 12-01-31 11:45 AM, "Shazron" <sh...@gmail.com> wrote:
>I'd rather wait until we all agree on supporting one .xml config
>rather than having interim changes (less friction for users
>upgrading).
>
>What about plugins? I see that android uses a plugins.xml
>
>As for icons and splash screens, unfortunately on iOS it has to be
>specified in the app's Info.plist and cannot be from an external
>source, since this is handled by the app itself and outside of our
>control.
>
>On Tue, Jan 31, 2012 at 11:38 AM, Filip Maj <fi...@adobe.com> wrote:
>> I think a spec that is way more pertinent to Cordova for solving this
>> problem (and also many others) is the config.xml spec. Anis pointed out
>> the <access> element. WebWorks already uses a config.xml file as a base
>> for defining application metadata and configuration. So does PhoneGap
>> Build. Tons of goodies in there that we can use on top of caching and
>> server whitelisting, such as:
>>
>> - icon definitions (<icon> element)
>> - generic preference/configuration elements (<preference>). I believe
>> phonegap build uses this for things such as locking orientation in an
>>app.
>> Basically anything in phonegap.xml can be mapped to <preference>
>>elements.
>> - <feature> element. *VERY* pertinent to defining which APIs you want
>>your
>> app to access. Essentially could replace plugins.xml in cordova
>>currently.
>> - <author>, <title>, <license>, <description> elements...
>> - free localization of strings (such as titles) as well as content by
>> piggybacking on xml:lang attributes for different elements.
>> - application entry point (entry page) definitions (<content>)
>> - finally, there is a <param> element that is a key:value pair. We could
>> map anything to this...
>>
>> PhoneGap Build extended the config.xml elements with a splash screen
>> (<splash>) element as well.
>>
>>
>> The possibilities are endless, and we have a pretty complete spec. Also
>> for icing on the cake, Michael Brooks and I are involved with the W3C
>> community group related to the widget spec so we already have ins to
>> present feedback and iterate on the spec if necessary.
>>
Re: Consistent implementation of the whitelist
Posted by Shazron <sh...@gmail.com>.
I'd rather wait until we all agree on supporting one .xml config
rather than having interim changes (less friction for users
upgrading).
What about plugins? I see that android uses a plugins.xml
As for icons and splash screens, unfortunately on iOS it has to be
specified in the app's Info.plist and cannot be from an external
source, since this is handled by the app itself and outside of our
control.
On Tue, Jan 31, 2012 at 11:38 AM, Filip Maj <fi...@adobe.com> wrote:
> I think a spec that is way more pertinent to Cordova for solving this
> problem (and also many others) is the config.xml spec. Anis pointed out
> the <access> element. WebWorks already uses a config.xml file as a base
> for defining application metadata and configuration. So does PhoneGap
> Build. Tons of goodies in there that we can use on top of caching and
> server whitelisting, such as:
>
> - icon definitions (<icon> element)
> - generic preference/configuration elements (<preference>). I believe
> phonegap build uses this for things such as locking orientation in an app.
> Basically anything in phonegap.xml can be mapped to <preference> elements.
> - <feature> element. *VERY* pertinent to defining which APIs you want your
> app to access. Essentially could replace plugins.xml in cordova currently.
> - <author>, <title>, <license>, <description> elements...
> - free localization of strings (such as titles) as well as content by
> piggybacking on xml:lang attributes for different elements.
> - application entry point (entry page) definitions (<content>)
> - finally, there is a <param> element that is a key:value pair. We could
> map anything to this...
>
> PhoneGap Build extended the config.xml elements with a splash screen
> (<splash>) element as well.
>
>
> The possibilities are endless, and we have a pretty complete spec. Also
> for icing on the cake, Michael Brooks and I are involved with the W3C
> community group related to the widget spec so we already have ins to
> present feedback and iterate on the spec if necessary.
>
Re: Consistent implementation of the whitelist
Posted by Filip Maj <fi...@adobe.com>.
I think a spec that is way more pertinent to Cordova for solving this
problem (and also many others) is the config.xml spec. Anis pointed out
the <access> element. WebWorks already uses a config.xml file as a base
for defining application metadata and configuration. So does PhoneGap
Build. Tons of goodies in there that we can use on top of caching and
server whitelisting, such as:
- icon definitions (<icon> element)
- generic preference/configuration elements (<preference>). I believe
phonegap build uses this for things such as locking orientation in an app.
Basically anything in phonegap.xml can be mapped to <preference> elements.
- <feature> element. *VERY* pertinent to defining which APIs you want your
app to access. Essentially could replace plugins.xml in cordova currently.
- <author>, <title>, <license>, <description> elements...
- free localization of strings (such as titles) as well as content by
piggybacking on xml:lang attributes for different elements.
- application entry point (entry page) definitions (<content>)
- finally, there is a <param> element that is a key:value pair. We could
map anything to this...
PhoneGap Build extended the config.xml elements with a splash screen
(<splash>) element as well.
The possibilities are endless, and we have a pretty complete spec. Also
for icing on the cake, Michael Brooks and I are involved with the W3C
community group related to the widget spec so we already have ins to
present feedback and iterate on the spec if necessary.
Re: Consistent implementation of the whitelist
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Jan 30, 2012 at 21:04, Shazron <sh...@gmail.com> wrote:
> During the 1.4.0 planning call, Anis proposed these requirements:
> 1. a consistent implementation of the whitelist across all platforms
>
yes!
> 2. follow the Opera standard (need a url to the docs for this,
couldn't find it using the obvious keywords)
>
following existing standards is great, but let's find the URL
> 3. white-listing should be documented on the docs site (Getting
> Started section)
>
yes!
> The only problem with iOS adopting this is the .plist format does not
> allow attributes in its xml. Right now the list of allowed hosts is
> just an array of strings, but to support "attributes" it would have to
> be an array of dictionaries. I could make this change but this
> satisfies neither requirements (1) nor (2).
>
Bending the iOS plist format seems wrong.
> Changing the iOS implementation to support a PhoneGap.xml list instead
> of .plist is another effort entirely, but better now than later -
> unless we are going to use config.xml. Thoughts?
>
Yes, let's go for complete consistency.
Another thought for a "standard" would be the app cache manifest. It's a
simple text file, with "stanzas". The applicable one here is the NETWORK
stanza, also referred to in the spec as the "online whitelist section".
Basic idea is each line is either '*' (and then you don't need any more
lines!) or a URL prefix. Any URLs you attempt to resolve that match a
prefix are allowed, others aren't. Full spec for app-cache here, the
details are not simplistic for the whole ball of wax. [1]
If we wanted to do this, I'd say we just support the notion of a white list
file with the contents corresponding to the NETWORK stanza of the app-cache
file.
I believe one other issue that has come up is whether there should be
separate white lists for "normal" URL accesses and child browser usage.
Easy to imagine some other plugin may want to take advantage of white
lists also.
[1] http://www.w3.org/TR/html5/offline.html
--
Patrick Mueller
http://muellerware.org
Re: Consistent implementation of the whitelist
Posted by Anis KADRI <an...@gmail.com>.
Hey,
Opera spec
http://dev.opera.com/articles/view/extensions-api-config-access/
W3C spec
http://www.w3.org/TR/widgets-access/#the-access-element
According to the above. * is only used to allow unlimited access to
any resources but it doesn't explicitly say that it can be used to
build regular expressions.
Not sure what to do about the iOS attribute limitation.
On Mon, Jan 30, 2012 at 6:04 PM, Shazron <sh...@gmail.com> wrote:
> During the 1.4.0 planning call, Anis proposed these requirements:
> 1. a consistent implementation of the whitelist across all platforms
> 2. follow the Opera standard (need a url to the docs for this,
> couldn't find it using the obvious keywords)
> 3. white-listing should be documented on the docs site (Getting
> Started section)
>
> I like the Opera standard (see Android implementation here for an
> example: https://github.com/apache/incubator-cordova-android/blob/master/framework/res/xml/phonegap.xml).
>
> The only problem with iOS adopting this is the .plist format does not
> allow attributes in its xml. Right now the list of allowed hosts is
> just an array of strings, but to support "attributes" it would have to
> be an array of dictionaries. I could make this change but this
> satisfies neither requirements (1) nor (2).
>
> Changing the iOS implementation to support a PhoneGap.xml list instead
> of .plist is another effort entirely, but better now than later -
> unless we are going to use config.xml. Thoughts?
Re: Consistent implementation of the whitelist
Posted by Brian LeRoux <b...@brian.io>.
> 1. a consistent implementation of the whitelist across all platforms
+1
> 2. follow the Opera standard (need a url to the docs for this,
> couldn't find it using the obvious keywords)
booya: http://dev.opera.com/articles/view/extensions-api-config-access/
> 3. white-listing should be documented on the docs site (Getting
> Started section)
+1
> Changing the iOS implementation to support a PhoneGap.xml list instead
> of .plist is another effort entirely, but better now than later -
> unless we are going to use config.xml. Thoughts?
I say kickup a branch that does the incremental phoengap.xml effort to
prototype it for now.