incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcos Caceres <>
Subject Re: Naviation Use Cases and whitelist
Date Fri, 03 Feb 2012 20:19:19 GMT

On Friday, 3 February 2012 at 20:06, Filip Maj wrote:

> The neat thing about config.xml is that the elements are
> composable/nestable.  

This is true to a degree…. The W3C spec defines the following algorithm to process XML files:
> WebWorks employs this for some of their stuff too,
> for example consider this use case that is doable in WebWorks with the
> help of config.xml:
> You set your app's <content> element to point to some start page within
> your app package, i.e. index.html. But you want to iterate on your app
> development faster, so instead of redeploying your app to clients every
> time you make a change, instead you change the start page to point to some
> page online, I.e. In
> webworks, you can nest the various elements inside each other, so you can
> do:
> <access origin="" subdomains="true">
> <content src="" />
> </access>

hmm… the WARP parsing algorithm would generally ignore such a construct (see [1]). However,
it could be coerced to work - but it would not be standards compliant.     


> This would explicitly allow the start page to be loaded from a remote
> location.

Also, the src attribute only accepts a Path to local file (I know, that's limiting… but
it was for historical/security reasons). However, in the new version of the spec [2], we could
certainly allow URLs (it was always the intention to allow them at some point, but we just
wanted to get widgets working locally).   

The current way to do the above is without modifying anything is…

<widget …>
<access origin="" subdomains="true">

 <doctype html>
 <iframe style="width:100%; height: 100%" src="">

> We could employ the same thing for plugins. Assuming plugin definitions
> would be specified declaratively in the config.xml with the help of
> <feature> elements, you could nest <feature> elements inside <access>
> elements, for example.
> I like this approach from a user of cordova perspective. The
> implementation will be a bit more challenging I think :r
> On 12-02-03 11:56 AM, "Shazron" < (>
> > > I *highly* suggest we employ config.xml as the abstraction for app
> > > configuration/metadata such as whitelisting, orientation locking,
> > > application naming, author info, etc. etc.
> >  
> >  
> >  
> > That's what we agreed (consensus?) in the other thread - one
> > config.xml to rule them all.
> >  
> > iOS has other issues with the implementation of the whitelist that is
> > not covered by the spec, like I already mentioned (whitelist exemption
> > for a particular component, like the ChildBrowser - see my proposal
> > for a mechanism for fixing this, earlier - and it is iOS specific)
> > unless this situation can be covered by the spec, which after looking
> > at the widgets access spec I don't think it is?

Marcos Caceres

View raw message