RE: Lisf to iPhone and iPad modelos

[Horn, Julian C]

Here's a useful URL: 
http://www.everyi.com/by-identifier/ipod-iphone-ipad-specs-by-model-identifier.html

This claims to list the model string for every Apple device.  For example, the 
model string for an iPhone 6s Plus is "iPhone8,2".

-Original Message-
From: Sergio Nader da Cunha Sardo [mailto:sergio.na...@gmail.com] 
Sent: Friday, January 01, 2016 3:53 PM
To: dev@cordova.apache.org
Subject: Lisf to iPhone and iPad modelos

Hello!

Happy New Year!

Where can I find a list of the returned values for the device.model for iOS 
devices? For instance, need to kown it the device is an iPad 2, 3, etc or an 
iphone 4, 5, 5S, 6, 6 Plus, etc

As I don't have all the phisical devices to test and considering the simulator 
does reports the same info as the real device, I'm lost (and could not find it 
anywhere)

Best regards,

​​
Sérgio Nader

Skype: sergio.nader.br

Tel: 55 11 9 9101 4590



​www.brasilisdigital.com.br

Tecnologia & Inovação​

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

RE: Scoped package names for npm?

[Horn, Julian C]

I am also against another rename.  These name changes are very costly and 
disruptive.

There is code in several places that assumes that you can enumerate the
plugins selected by a project by enumerating the subdirectories of plugins.
If you allow a plugin root folder to be more than a single directory,
like "@cordova/plugin-device" then you break that code.

Also, please remember that when you rename a plugins, you require people
to update every  tag that refers to that plugin, unless you
want to rely on the rename machinery forever.

Julian

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com] 
Sent: Monday, April 20, 2015 9:42 PM
To: dev@cordova.apache.org
Subject: Re: Scoped package names for npm?

I also like scoped packages but am against another rename. Haha.

I know organizations are coming soon so we will be able to create the Cordova 
organization and I believe scope packages that way. Add PMC members to the 
organization to be able to publish instead of relying on a Cordova npm user 
account.

Lets wait and see how it goes.
On Apr 20, 2015 2:29 PM, "Jesse"  wrote:

> re: the scoped package id, I like it, but not sure we want to change 
> them again ... and how much of our existing world will it break. Can 
> we install an '@' id currently on all platforms? It will result in a 
> www/plugins/@cordova/plugin-device/ folder right now, won't it?
>
> re: other questions
> Personally, I would rather see only committers able to publish to our 
> scope (assuming we go that way), just like we wanted to prevent non 
> committers from using org.apache.cordova namespace.
>
> I considered 'cordova plugin add device' awhile back, I was going to 
> do it directly in plugman, but I decided against it. Currently it 
> would mean a 3rd attempt to find the plugin over http; 1) cpr, 2) npm, 
> 3)munge name and go back to npm By this time, I think I would just ask 
> the user what they really want.
> We could also do this via cordova-registry-mapper aliases.
>
>
>
> @purplecabbage
> risingj.com
>
> On Mon, Apr 20, 2015 at 2:13 PM, Parashuram N (MS OPEN TECH) < 
> panar...@microsoft.com> wrote:
>
> > Scopes are like namespaces. In the reverse domain name world, 
> > org.apache.cordova was considered a namespace, right ?
> >
> > We did not want non core packages to publish to that namespace, so 
> > does the same argument apply ?
> >
> > Alternatively, we can think of scope as packages that apply to a 
> > particular environment - for example, all cordova packages would be 
> > @cordova scope.
> >
> > -Original Message-
> > From: Michal Mocny [mailto:mmo...@google.com]
> > Sent: Monday, April 20, 2015 2:03 PM
> > To: dev
> > Subject: Re: Scoped package names for npm?
> >
> > Other questions to answer:
> > - Can 3rd-parties publish to this scope?
> >   - Do we want them to?
> > - Do we want to default to @cordova scope if none is provided, such 
> > that you could do `cordova plugin add device`?
> >
> > -Michal
> >
> >
> > On Mon, Apr 20, 2015 at 5:00 PM, Michal Mocny  wrote:
> >
> > > https://docs.npmjs.com/getting-started/scoped-packages
> > >
> > > Should we be @cordova/plugin-device instead of cordova-plugin-device?
> > >
> > > -Michal
> > >
> >
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

RE: Simulating Cordova plugins and device capabilities

[Horn, Julian C]

I'll try to follow up on Tim's remark as eloquently as I can ;)

There are clearly advantages to building device simulation into the browser, 
but this strategy does impose limitations.  A company like Microsoft or Google 
has complete control over the browser and the debug tools, but this freedom 
does not exist for other vendors making their own emulator.  This creates the 
feeling of a closed system.

Intel has a rich history of creating software development tools for new 
hardware as it being designed.  We prize the ability to quickly support new 
devices of our choosing, so an open architecture is better for our needs.

Beyond that I see some shortcomings in the way the emulation features in Chrome 
and Internet Explorer work today.  The attributes of a device, once selected, 
cannot be modified by the program under test (or even by the non-browser parts 
of the emulator).  This makes it impossible to simulate any actions that change 
the size of the viewport.  For example, the show/hide status bar APIs cannot be 
simulated under these conditions, nor can other popular plugins such as AdMob 
that reduce the size of the viewport to allow room for advertisements. The 
device sizes provided in Chrome and Internet Explorer all assume a “full 
screen” configuration, that is, no status bar.  This is a reasonable choice if 
you are simulating a mobile browser.  However, most packaged apps run with a 
status bar.  This means the device sizes provided by browsers are in fact 
uniformly incorrect for most packaged apps.

In our experience, the photorealistic device skins are surprisingly effective 
in getting across the feeling of what an app would look like running on a real 
device.  We heard from one customer who develops apps for a living.  For less 
technical customers a prototype of an app he would build running in the XDK 
Device Emulator to show what the app would feel like.  We lose this capability 
if we entrust the device emulation problem to the browser.

   Julian

-Original Message-
From: Tim Barham [mailto:tim.bar...@microsoft.com] 
Sent: Wednesday, March 25, 2015 1:50 AM
To: dev@cordova.apache.org
Subject: RE: Simulating Cordova plugins and device capabilities

Thanks Michal and Jesse!

Jesse, in response to your additional questions...

> What value does Ripple  if the basic functionality becomes part of a 
> generic simulation interface?
>
> Ripple currently will simulate screen sizes based on device choice. 
> Chrome dev tools support picking different device viewports also.  
> Where should something like this live?

Julian Horn (Intel) would be a good person to answer that question... He can 
speak more eloquently than me to why Ripple is (and will continue to be, after 
this proposal is implemented) the ideal platform for them. And I think there is 
definitely room for both approaches:

* Some basic simulation host provided by Cordova, which wouldn't provide any of 
the "device choosing" capabilities and other functionality we get with Ripple, 
but would work well with browser dev tools (and rely on them to provide that 
functionality).
* A richer environment like Ripple, which is also works well embedded in tools 
like the XDK.

Another interesting point is that Chrome device mode means you have the Chrome 
debugger open, which means you can't use an external debugger. If your workflow 
is entirely Chrome, then that works very well. If we're talking about using 
Chrome with external debuggers (like Intel XDK or Visual Studio), then device 
mode becomes problematic and something like Ripple works well.

> Is this feature valuable enough to warrant this lengthy discussion?

It's certainly valuable to certain groups :). But for me I think it's more a 
case that it will involve a significant amount of effort and I want to get sign 
off from the community now rather than spending a bunch of time going down a 
path that might get rejected down the line.

Thanks again!

Tim

-Original Message-
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Wednesday, March 25, 2015 8:32 AM
To: dev
Subject: Re: Simulating Cordova plugins and device capabilities

This is exceptionally cool (and thanks for doing a video demonstration, great 
way to get the point across)!

I also agree with all your points, and really support this approach.
Specifically:

+1 browser platform will be used for both prod and debugging, so cannot
have always-on emulation.
+1 to have emulation hooks inside cordova browser platform and cordova
plugins' browser versions, but have them no-op by default.
+1 to support any downstream emulation embedders, and perhaps have a 
+very
lightweight cordova project (though perhaps not necessary beyond a simple 
testing app).
+1 to suggest Ripple become an embedder.

I'll also note that Microsoft is one of the primary supporters of Ripple 
recently, so if they think this is a good direction, that is a strong signal to 
me.  Intel is a second strong s

RE: Plugins to NPM (Phase 1)

[Horn, Julian C]

I'd like to add some more questions to what Leo asked.

Can anyone explain how the hundreds of plugins that are published in git repos 
are supposed to transition to CLI 5 (and beyond)?  It seems like the answer is 
that they don't change anything.  What if they want to (or already do) publish 
via the registry?  It seems like you can win if you keep the id unchanged and 
add yourself to the mapping table.  But if that's true, then why are we 
renaming the core plugins?

I don't think repo-resident plugins need to update any  tags that 
refer to core plugins.  That is, you can continue to ask for 
"org.apache.cordova.file".  If you use CLI 5, then the rename logic will get 
you the corresponding plugin from npm.  Or is there some reason why you will 
eventually have to change your  tags to use the new names.  Of 
course you better not change a  tag in your repo-resident plugin 
before October 1, because that will break projects that use your plugin but 
aren't yet using CLI 5.

I haven't been able to come up with any strategy for changing the id of a 
repo-resident plugin without great pain.  It's basically equivalent to 
discontinuing your plugin and creating a new one in its place.  So it seems to 
me that if I have any users I would probably want to stick with my existing id 
and repo URL, even if it meant that I couldn't publish my plugin in npm format. 
 Is that a viable strategy, or is there a long term plan that EVERY plugin must 
eventually publish via npm?

One final question.  Suppose I have a CLI 4.x project and I want to transition 
to CLI 5.  Do I have to start over at "cordova create project"?

Julian

-Original Message-
From: Treggiari, Leo [mailto:leo.treggi...@intel.com] 
Sent: Wednesday, March 25, 2015 3:53 PM
To: dev@cordova.apache.org
Subject: RE: Plugins to NPM (Phase 1)

Thanks for the information Steve.  That helps with our planning.  I have a 
couple of follow-ups.

> We don't necessarily have to do a major bump for the CLI. We could 
> easily save the major jump until we switch npm fetching as default 
> (approx July 1)

Re: the major bump.  This seems like a "delayed" breaking change.  That is, 
when CPR is removed, all prior CLI releases will be "crippled" to a significant 
degree since no  reference will be able to be resolved. 

Re: ~July 1:  Would you verify my understanding?  For a  reference 
which is not in the mapping table, from ~Apr to ~July 1, CPR will be tried 
first and if that fails then npm.  From ~July 1 to ~Oct 1, npm will be tried 
first and if that fails then the CPR.  After ~Oct 1, only npm.

Thanks,
Leo 

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Wednesday, March 25, 2015 11:13 AM
To: dev@cordova.apache.org
Subject: Re: Plugins to NPM (Phase 1)

Thanks for answering tony. More comments below.

On Tue, Mar 24, 2015 at 12:45 PM, Homer, Tony  wrote:

> I¹ll try to answer some of Leo¹s questions, but it would be great if 
> someone else (Steve?) could comment.
>
> First, though, I¹ll ask a question of my own.
> Is there a doc or JIRA task for tracking all of the activity related 
> to moving plugins to NPM?
> There was the Google Doc that was created last hangout for tracking 
> the proposal, but it doesn¹t list JIRAs and hasn¹t been updated since 
> January.
> I found CB-8529, CB-8538 and CB-8551 but they are not linked to a 
> master task JIRA.
> This is not a jab at Steve at all, I¹m just wondering if there is or 
> should be a reference for this set of tasks (other than staying caught 
> up with reading the list)?
>

Good point. I have created a master issue at
https://issues.apache.org/jira/browse/CB-8743


> On to Leo¹s questions-
>
> Will the release be named Cordova 5.0?
> Unknown at this time?  It seems like this will require a co-ordinated 
> release of CLI, Tools and Plugins, with major version bumps for all.
>

We haven't discussed this yet. We don't necessarily have to do a major bump
for the CLI. We could easily save the major jump until we switch npm
fetching as default (approx July 1)

>
> Will it trigger a major revision bump?
> Yes.
>

For plugins, yes. All of the core plugins will be getting a major version
bump shortly.

>
> What is the current estimate for the release?
>
> I would say ³when it¹s done² but it would be great to get a more specific
> answer.
> I¹m not sure if that¹s possible?
>

Aiming for April 1st.

>
> If release of Phase 1 occurs on April 1 does this mean that the CPR
> becomes read-only on July 1 and is
> deleted on Oct 1?

I think the real driver was that there is an external hosting issue with
> CPR after Oct. 1.
> The 3 month period was adopted so provide a transition window, but there
> is a hard stop on or around Oct. 1.
> Steve had mentioned this somewhere but I can¹t find it now.
>

- CPR becomes read-only July 1st (if we release April 1st)
- Tools fetch from NPM by default on July 1st (currently checks CPR first,
npm as fallback)
- We will try to keep CPR open as r

RE: Introduction for Julian Horn

[Horn, Julian C]

Well, I can see that this is kind of a philosophical disagreement.

Today having two 

RE: Introduction for Julian Horn

[Horn, Julian C]

Hi Jesse,

While it's certainly true that it's impossible to bullet-proof Cordova, 
protection against multiple inclusion is pretty basic.  All the C system 
include files protect against multiple inclusion.  JavaScript objects like 
jQuery include code to tolerate multiple inclusion.  We should too.

The fix certainly does not require a large chunk of time!  Here's the entire 
fix; you put this up near the top of cordova.js, inside the outermost function 
invocation:

if (window.cordova) {
return;
}

To appreciate why this matters, I think you have to cultivate a product 
viewpoint.  The Intel XDK is a development toolkit that attempts to make 
cross-platform HTML5 more approachable.  Obviously, as people get farther into 
HTML5 development they will run into all kinds of hard problems.  But right out 
of the box, you want people to be able to put together simple apps simply.  
That kind of good initial experience is a key to making an approachable 
product. 

This particular mistake, of including two 

Introduction for Julian Horn

[Horn, Julian C]

Hello!  I am Julian Horn.  I'm a software engineer in the Intel XDK team.  I am 
the team lead for the Device Emulator component, our derivative of the Ripple 
emulator.

I have signed and sent in an individual contributor agreement, and my company 
has a corporate contributor agreement signed.
I have posted mail to this mail list and to the ripple mailing list before, but 
this will be my first contribution.

To get my feet wet, I would like to take on CT-7792.  This is a small JIRA I 
filed that complains about what happens if a user accidentally codes two 

RE: Does this plugin support the current platform?

[Horn, Julian C]

I like it!

-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Tuesday, February 10, 2015 3:52 PM
To: dev
Subject: Re: Does this plugin support the current platform?

Strawman:

If plugin.xml has *any* s, then only apply global tags to those 
platforms.
If plugin.xml has *no* s, then apply global tags to all platforms.

On Tue, Feb 10, 2015 at 2:18 PM, Tommy Williams  wrote:

> This won't actually help right now, but that feature detection would 
> actually be possible if the plugin's "clobbers" was always a child of 
> the "platform" in plugin.xml.
>
> Right now, most plugins have their clobbers global to all platforms, 
> supported or not. If the clobbers is a child of the platform, then the 
> relevant js function/object would be undefined on an unsupported platform.
>
> This practice would also help in a situation where you might want 
> different plugins for different platforms, but exposing similar 
> functionality on one clobbered function/object (eg: the popular 
> barcode scanner plugin + the blackberry barcode scanner plugin).
>
> Unfortunately, most plugins don't do this, even though it is possible.
> The natural way to determine whether some functionality is available 
> is to use the "feature detection" pattern.  That is, if you want to 
> call some function normally found at "myobj.myfunc", you write code like this:
>
> If (myobj && (typeof myobj.myfunc === 'function')) ...
>
> For this to work you must take care to remove plugins that don't 
> support your platform before you build for that platform.  For 
> example, before you build for firefoxos, you must remove the 
> barcodescanner plugin (and then add it back when you build for 
> supported platforms).  Granted, this is awkward, but I think it's worse to 
> read the package.json file.
>
> Really the CLI should make the feature detection pattern work without 
> having to exclude plugins on unsupported platforms.  That is, if a 
> plugin doesn't support a platform, then it should contribute nothing 
> when you build for that platform.
>
> Julian
>
> -Original Message-
> From: Axel Nennker [mailto:ignisvul...@gmail.com]
> Sent: Tuesday, February 10, 2015 11:48 AM
> To: dev
> Subject: Re: Does this plugin support the current platform?
>
> And then the app has to load that package.json ?
> On Feb 10, 2015 5:28 PM, "Steven Gill"  wrote:
>
> > Plugin.xml has a platforms tag for what platforms it supports. That 
> > info gets uploaded to the Cordova plugins registry when publishing.
> >
> > Soon this info will be available in package.json file each plugin has.
> > On Feb 10, 2015 7:25 AM, "Axel Nennker"  wrote:
> >
> > > Hi,
> > >
> > > is there a way how an app can determine whether a plugin supports 
> > > the current  platform?
> > >
> > > E.g.: the barcodescanner plugin is not supporting firefoxos How 
> > > could an app know that which out hardcoding this into the app?
> > >
> > > If there is a standard way in Cordova then this is a userland question.
> > > If not then this is a feature request to add this info to e.g.
> > > cordova/plugin_list exports.metadata ?!
> > >
> > > -Axel
> > >
> >
>

RE: Plugin Install Hooks

[Horn, Julian C]

Actually I see it the other way around.  If you want to trust a plugin, you can 
make that decision; it's your machine.  The build server doesn’t trust the 
plugins you trust.

-Original Message-
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Tuesday, February 10, 2015 11:27 AM
To: Michal Mocny
Cc: dev
Subject: Re: Plugin Install Hooks

..Not to mention, these plugins will be running on end users' personal devices. 
 That sounds vastly more concerning than running hooks on a server you control 
and can sandbox.

On Tue, Feb 10, 2015 at 11:25 AM, Michal Mocny  wrote:

> So, I think this is not different than downloading and running 
> packages from any package manager.
>
> That said, I think a --suppress-hooks flag would be fine.  I suggest 
> you file a JIRA so others can chime in, and if you want it to land 
> soon I would take a stab at a PR.
>
> -Michal
>
> On Tue, Feb 10, 2015 at 10:02 AM, Horn, Julian C 
> 
> wrote:
>
>> Thanks for the pointer Shazron.  I read through all of this 
>> interesting discussion.  I agree that sandboxing is hard and prompting is 
>> problematic.
>> But there's still an issue here.
>>
>> If there is no mechanism to exclude scripting in untrusted plugins 
>> then build servers are unlikely to accept any uncurated plugin, which 
>> is what PGBuild is doing.  The Intel XDK provides a build server.  We 
>> would like to support arbitrary third party plugins, not just ones we 
>> have curated.  This install-time hooks feature creates a major 
>> security issue for us. Under no circumstances are we going to allow 
>> untrusted native code to run on our build server.
>>
>> And thanks to Sergey for pointing out that issue with pre_package hooks!
>> We were under the impression that project-level hooks could be 
>> suppressed by excluding the hooks directory. I see now that this isn't 
>> sufficient.
>>
>> I have a very simple suggestion: add a "--suppress-hooks" flag.  This 
>> doesn't prompt: it assumes the answer to the prompt is "no".
>>
>> I don't have enough experience with install hooks to know if the 
>> plugin is likely to be usable without running the install-time hook.  
>> I expect that if you add a plugin that contains an install time hook 
>> and --suppress-hooks is present, then the plugin add should fail.  If 
>> there's some reason to believe that a plugin could be usable without 
>> running the install time hook, then maybe it would be interesting to 
>> have a variant of --suppress-hooks that bypasses the hook but allows 
>> the plugin to be installed anyway.
>>
>> I would also expect that --suppress-hooks would suppress pre_package 
>> time hooks too.
>>
>> Julian
>>
>> -Original Message-
>> From: Shazron [mailto:shaz...@gmail.com]
>> Sent: Monday, February 09, 2015 4:21 PM
>> To: dev@cordova.apache.org
>> Subject: Re: Plugin Install Hooks
>>
>> We did discuss this, and we rejected:
>> 1. Having a prompt
>> 2. Sandboxing
>>
>> Check out the discussion, for reasons:
>> http://markmail.org/message/alknczhqdghaurrw
>>
>> On Mon, Feb 9, 2015 at 8:28 AM, Horn, Julian C 
>> 
>> wrote:
>> > We have identified a security issue with the recently added feature 
>> > of
>> install-time plugin hooks.
>> >
>> > As far as I can tell, there is nothing that prevents creation of a
>> plugin with a malicious install-time hook script.  Adding that plugin 
>> to a project could corrupt the user's host machine.  If that project 
>> using that plugin is submitted to a build server, then the build 
>> server could be corrupted.
>> >
>> > Yes, you can use lower level plugman scripts to fetch plugins and 
>> > then
>> pre-scan them for install time hooks and track down all the 
>> dependencies and scan them too.  So this is fixable (on a build 
>> server), but it's a lot of extra work; "cordova plugin add" should not be an 
>> unsafe operation.
>> >
>> > I propose that the CLI should check to see if a plugin requires an
>> install-time hook and require the user to explicitly grant permission 
>> before executing the install hook.  A build server would always deny 
>> permission.
>> >
>> > Is there something I'm missing here?
>> >
>> > Julian
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

RE: Does this plugin support the current platform?

[Horn, Julian C]

The natural way to determine whether some functionality is available is to use 
the "feature detection" pattern.  That is, if you want to call some function 
normally found at "myobj.myfunc", you write code like this:

If (myobj && (typeof myobj.myfunc === 'function')) ...

For this to work you must take care to remove plugins that don't support your 
platform before you build for that platform.  For example, before you build for 
firefoxos, you must remove the barcodescanner plugin (and then add it back when 
you build for supported platforms).  Granted, this is awkward, but I think it's 
worse to read the package.json file.

Really the CLI should make the feature detection pattern work without having to 
exclude plugins on unsupported platforms.  That is, if a plugin doesn't support 
a platform, then it should contribute nothing when you build for that platform.

Julian

-Original Message-
From: Axel Nennker [mailto:ignisvul...@gmail.com] 
Sent: Tuesday, February 10, 2015 11:48 AM
To: dev
Subject: Re: Does this plugin support the current platform?

And then the app has to load that package.json ?
On Feb 10, 2015 5:28 PM, "Steven Gill"  wrote:

> Plugin.xml has a platforms tag for what platforms it supports. That 
> info gets uploaded to the Cordova plugins registry when publishing.
>
> Soon this info will be available in package.json file each plugin has.
> On Feb 10, 2015 7:25 AM, "Axel Nennker"  wrote:
>
> > Hi,
> >
> > is there a way how an app can determine whether a plugin supports 
> > the current  platform?
> >
> > E.g.: the barcodescanner plugin is not supporting firefoxos How 
> > could an app know that which out hardcoding this into the app?
> >
> > If there is a standard way in Cordova then this is a userland question.
> > If not then this is a feature request to add this info to e.g.
> > cordova/plugin_list exports.metadata ?!
> >
> > -Axel
> >
>

RE: Plugin Install Hooks

[Horn, Julian C]

Thanks for the pointer Shazron.  I read through all of this interesting 
discussion.  I agree that sandboxing is hard and prompting is problematic.  But 
there's still an issue here.

If there is no mechanism to exclude scripting in untrusted plugins then build 
servers are unlikely to accept any uncurated plugin, which is what PGBuild is 
doing.  The Intel XDK provides a build server.  We would like to support 
arbitrary third party plugins, not just ones we have curated.  This 
install-time hooks feature creates a major security issue for us. Under no 
circumstances are we going to allow untrusted native code to run on our build 
server.

And thanks to Sergey for pointing out that issue with pre_package hooks!  We 
were under the impression that project-level hooks could be suppressed by 
excluding the hooks directory. I see now that this isn't sufficient.

I have a very simple suggestion: add a "--suppress-hooks" flag.  This doesn't 
prompt: it assumes the answer to the prompt is "no".

I don't have enough experience with install hooks to know if the plugin is 
likely to be usable without running the install-time hook.  I expect that if 
you add a plugin that contains an install time hook and --suppress-hooks is 
present, then the plugin add should fail.  If there's some reason to believe 
that a plugin could be usable without running the install time hook, then maybe 
it would be interesting to have a variant of --suppress-hooks that bypasses the 
hook but allows the plugin to be installed anyway.

I would also expect that --suppress-hooks would suppress pre_package time hooks 
too.

Julian

-Original Message-
From: Shazron [mailto:shaz...@gmail.com] 
Sent: Monday, February 09, 2015 4:21 PM
To: dev@cordova.apache.org
Subject: Re: Plugin Install Hooks

We did discuss this, and we rejected:
1. Having a prompt
2. Sandboxing

Check out the discussion, for reasons:
http://markmail.org/message/alknczhqdghaurrw

On Mon, Feb 9, 2015 at 8:28 AM, Horn, Julian C  wrote:
> We have identified a security issue with the recently added feature of 
> install-time plugin hooks.
>
> As far as I can tell, there is nothing that prevents creation of a plugin 
> with a malicious install-time hook script.  Adding that plugin to a project 
> could corrupt the user's host machine.  If that project using that plugin is 
> submitted to a build server, then the build server could be corrupted.
>
> Yes, you can use lower level plugman scripts to fetch plugins and then 
> pre-scan them for install time hooks and track down all the dependencies and 
> scan them too.  So this is fixable (on a build server), but it's a lot of 
> extra work; "cordova plugin add" should not be an unsafe operation.
>
> I propose that the CLI should check to see if a plugin requires an 
> install-time hook and require the user to explicitly grant permission before 
> executing the install hook.  A build server would always deny permission.
>
> Is there something I'm missing here?
>
> Julian

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Plugin Install Hooks

[Horn, Julian C]

We have identified a security issue with the recently added feature of 
install-time plugin hooks.

As far as I can tell, there is nothing that prevents creation of a plugin with 
a malicious install-time hook script.  Adding that plugin to a project could 
corrupt the user's host machine.  If that project using that plugin is 
submitted to a build server, then the build server could be corrupted.

Yes, you can use lower level plugman scripts to fetch plugins and then pre-scan 
them for install time hooks and track down all the dependencies and scan them 
too.  So this is fixable (on a build server), but it's a lot of extra work; 
"cordova plugin add" should not be an unsafe operation.

I propose that the CLI should check to see if a plugin requires an install-time 
hook and require the user to explicitly grant permission before executing the 
install hook.  A build server would always deny permission.

Is there something I'm missing here?

Julian

RE: Summarizing thoughts on cordova-browser vs Ripple

[Horn, Julian C]

I'd like to answer some of the concerns that have flown by in this thread.  Let 
me work from most recent to older.

First, in reply to Jesse's question, yes, this is how Ripple works today: it 
can run code prepared for any platform.  That is, when you start to emulate a 
Cordova 3 project, Ripple calculates the platform associated with the currently 
selected device.  So if the current device is an iPhone 5, the platform is 
"ios".  Ripple then shells out to run a "cordova prepare ios".  When that 
finishes, Ripple starts executing the output, which would be in 
platform/ios/www.  This means you are executing the ios-specific sources for 
your app under ios emulation.  If you have any merges, they would be resolved 
according to the ios rules.

The point of the cordova-browser and ripple-as-a-platform idea is to stop doing 
this, and rather have Ripple shell out to do "cordova prepare browser" (or 
"cordova prepare ripple") no matter what device is selected.  This means you 
are executing not os-specific sources, but rather generic sources that are 
intended on a browser (or in a browser in ripple).  The distinction between 
these two cases is what started this mail thread.

I think Serge what is saying that he likes the possibility of being able to 
package the emulation support for a plugin API in with the plugin itself, 
rather than having all the emulation support be in the emulator, as has been 
the case in the past.  This provides a nice extensibility point that plugin 
authors could use as they see fit.

As for Brian's question about UI support in plugins, it's certainly true that 
anyone who wants to design a UI model for emulation of some new API will have 
to work within some extensible GUI context.  This is really what Ripple gives 
you.  The browser does not, and it seems unlikely that the developer tools in 
multiple browsers could agree on some kind of common extensibility framework.

For example, the Ripple UI provides the concept of a "panel".  This is a 
separable module that is defined by its own HTML and CSS, along with whatever 
images or third party components are needed to make it all work.  It's easy to 
add a panel to Ripple, and with that you get for free a framework where that 
panel can be opened, closed, hidden, and arranged within an accordion with 
other panels and so on. I made a prototype version of Ripple that demonstrates 
that it is possible to embed a panel definition into a plugin and have Ripple 
discover that panel and dynamically add it to the rest of the Ripple UI, as if 
it were part of Ripple to begin with.  So this is certainly doable.  It's the 
same amount of work to author and maintain the emulation code, no matter how it 
is packaged.

As to whether Ripple is "dead" or not, I would like to point out that Intel has 
a Ripple-derived product (we call it the Device Emulator) that is alive and 
well.  It does not run as a stand-alone tool, but rather is integrated into the 
Intel XDK IDE.  It is under active development and support.  It has diverged 
somewhat from Ripple, mainly in the way it is integrated into the XDK and the 
way it supports Cordova 3.  For example, we have an "auto-refresh" option that 
causes the emulator to restart when you modify a source file.  We also have a 
button that launches a variant of the developer tools that appears to debug 
only the program under test, even though this is just one frame in a larger 
document.

Julian

-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com] 
Sent: Tuesday, November 18, 2014 4:04 PM
To: dev@cordova.apache.org
Subject: Re: Summarizing thoughts on cordova-browser vs Ripple

Shouldn't ripple be able to emulate/monkey-patch any of the platforms?
If I am looking at and testing my cordova-ios app in ripple, I think I would 
want the cordova-ios.js to be run, and not cordova-browser.js, otherwise there 
could be latent issues that I would never see until I actually ran it on the 
device, or emulator.  Hopefully the differences between each platform's 
cordova.js is insignificant, but I don't think that we know this for sure.

The code to inject/intercept ANY platform's cordova.exec is simple, really, it 
is <10 lines.
In my mind, ripple should be responsible for hooking it's own way in, and 
proxying, without extra specific built in support either by cordova-browser, or 
cordova-js.


@purplecabbage
risingj.com

On Tue, Nov 18, 2014 at 11:49 AM, Michal Mocny  wrote:

> Serge,
>
> That sounds like you disagree with Julian's earlier summary that 
> Ripple should just intersect at the exec proxy level, and propose 
> instead that Ripple should intersect by having "hooks" inside the 
> cordova-browser plugin js-modules, correct?
>
> I think thats not impossible (plugin authors can do what they want), 
> but perhaps should just happen on a case-by-case basis, as required.  
> If you have ideas about an architecture that we should advise 
> developers to use by default, I'm curious what 

RE: Summarizing thoughts on cordova-browser vs Ripple

[Horn, Julian C]

Yes, that's absolutely right.  The ripple and browser platforms can coexist, 
and you can refer to the API implementations in the cordova-browser platform 
from the ripple platform.

You can imagine how this would work.  The exec call should land in the ripple 
implementation of the API.  That code can decide whether it needs to delegate 
to the browser implementation of the API.  (It could use UI to guide this 
decision.) If so, it finds the browser implementation via execProxy and invokes 
it.

This is easy when the ripple implementation is built in.  Ripple's 
implementation of "exec" separates the Services registered with Ripple from 
those that self-register with execProxy. Ripple therefore can prefer its own 
implementation when both exist. When the ripple and browser implementations are 
both in the same plugin then you have a conflict because both of them want to 
self-register as the same service.  Still, I'm confident that this can be 
sorted out.

For example, say the JS part of a plugin calls exec for service S, function F.  
The browser implementation self-registers with execProxy as S.  The ripple 
implementation could self-register as "Ripple S".  When asked to invoke a 
function in service "S", the Ripple exec function can look for the object 
registered as "Ripple S" before looking for the object registered as "S".  Easy.

Julian

-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Friday, November 14, 2014 4:07 AM
To: dev
Subject: Re: Summarizing thoughts on cordova-browser vs Ripple

From reading this, seems like it could work well to have plugins provide both 
browser and ripple implementations. They could make them the same, or have the 
ripple one provide some sort of nice emulation UI. e.g.

var div = ... createUI;
ripple.registerPluginUi(div)

Still also seems powerful though, to have Ripple be able to add UI for plugins 
that don't provide their own.


On Mon, Nov 10, 2014 at 3:48 PM, Michal Mocny  wrote:

> On Thu, Nov 6, 2014 at 6:52 PM, Horn, Julian C 
> 
> wrote:
>
> > I'd like to introduce myself and put in my two cents here. My name 
> > is Julian Horn.  I work for Intel on the XDK, an integrated 
> > development environment for cross-platform HTML5 applications.  I am 
> > the team lead
> for
> > the Device Emulator component, which is our Ripple derivative.  My 
> > background is mostly in software development tools: compilers, 
> > debuggers, simulators and analysis tools. I have been working with 
> > the Ripple code base for a couple of years now.
> >
> > If I'm understanding the cordova-browser concept, the implementation 
> > of a Cordova API for the browser platform should consist of code 
> > that bridges between the platform-independent Cordova API and 
> > whatever equivalent is available in the current browser session.  
> > For example, the camera API getPicture function would invoke the 
> > getUserMedia API, which is the
> closest
> > thing we have to a W3C standard way to take a picture.  If the 
> > browser doesn't implement this API or the host system doesn't have a 
> > camera, then the getPicture call fails with "camera unavailable".
> >
> > This seems like a fine way to gradually migrate from packaged apps 
> > that rely on native code plugins to pure web apps that rely on the 
> > browser to access mobile device resources.  This should work great 
> > when you have a browser-portable implementation.  It may be a 
> > challenge with some
> plugins,
> > since of course Cordova/PhoneGap was designed to cover gaps in 
> > browser support.  But at least we don't have to wait for a real W3C 
> > standard to
> be
> > agreed.
> >
> > The goal of our XDK product is to facilitate development of
> cross-platform
> > mobile HTML5 applications.  We see the Device Emulator (our Ripple) 
> > as enabling developers to test an HTML5 mobile application on the 
> > host system.  While this is no substitute for testing on real 
> > hardware, the Device Emulator does offers some advantages that can 
> > accelerate the development process.  To summarize quickly:
> >  * It’s really fast.
> >  * You don't need an array of mobile devices.
> >  * You can put off dealing with weird target system quirks until 
> > after
> you
> > get your basic application logic debugged.
> >  * You get full native JavaScript debugging, which is faster, 
> > simpler,
> and
> > more available than remote debug.
> >  * You can create testing situations that are difficult or 
> > impossible to create in real life, such as GPS timeo

RE: Questions re: plugin variables

[Horn, Julian C]

Thanks, that clears everything up.

It seems the fact that  tags don't work inside  tags is a 
bug.
Fortunately there is no advantage to putting a  tag inside and 
everyone seems to put them outside.

Julian

-Original Message-
From: Shazron [mailto:shaz...@gmail.com] 
Sent: Wednesday, November 12, 2014 6:38 PM
To: dev@cordova.apache.org
Subject: Re: Questions re: plugin variables

I know it seems confusing, but the  tag inside the  
tag is just some xml insertion into the config.xml file that is specified, but 
is not related to the  tag specified for plugin.xml. It is the 
 tag for config.xml.

It should behave as specified in the Plugin Spec [1], when inside  
tags, except for what I explained above.

Answering your points:
1) Yes, it ignores the value attribute, only 'name' is applicable per the spec.
2) They shouldn't be ignored if inside the  node, seems to be a bug 
(unless the tool is smart enough to know if the variable is actually being used 
and not prompt -- but that seems to be bad design)


[1]
http://cordova.apache.org/docs/en/4.0.0/plugin_ref_spec.md.html#Plugin%20Specification


On Fri, Nov 7, 2014 at 7:18 AM, Horn, Julian C 
wrote:

> Leo's question really hasn't been answered yet.  Let me try to make 
> this more concrete and see if anyone can explain whether the current 
> behavior of the CLI is correct or not.
>
> The plugin.xml in the StatusBar plugin contains the following content:
>
> ...
> 
> .
>   ...
>   
>
> There are several mysteries here.
>
> 1) What does it mean if the name attribute of a preference tag does 
> not obey the "only capital letters, digits, or underscores" rule?  
> Apparently it can never cause variable replacement.
> 2) What does the value attribute mean?  Does this supply a default 
> value for a variable if the variable is not mentioned in the 
> --variable flag (thus making the variable "optional")?
> 3) Where can  tags legally appear?  Must they be outside 
> of  tags, or can they be inside  tags or even 
> inside  tags?
>
> Our experiments with CLI 4.0.1-dev show the following:
>
> 1) The value attribute is ignored by the CLI, or at least it doesn't 
> create a default value.
>
> For example, suppose you put the following preference tag outside of 
> any  tag.
>  We found that the 
> user is still required to supply --variable API_KEY, which means that 
> "my-api-key" never becomes the value of API_KEY.
>
> 2)  tags appear to be ignored by the CLI if they appear 
> below a  node.
>
> If you move the  node shown above from outside a 
>  node to inside a  node, then the CLI stops 
> prompting for a --variable flag and $API_KEY is not replaced by anything.
>
> It looks to us like the  tag is overloaded.  When it 
> appears outside the  tag it defines a variable.  When it 
> appears inside a  tag it does not.  The meaning of the 
>  tag within a  tag is apparently determined by the 
> platform.
>
> If people agree that this is correct then the documentation can be 
> updated accordingly.  However, we did see some code in the 
> implementation that seemed to be looking for  tags inside 
> of  tags.  It seems like this isn't working as intended, but 
> then again we can't figure out what the intention is.
>
> Julian
>
> -Original Message-
> From: Marcel Kinard [mailto:cmarc...@gmail.com]
> Sent: Friday, November 07, 2014 9:42 AM
> To: dev@cordova.apache.org
> Subject: Re: Questions re: plugin variables
>
> If there is a reasonable question from a user, it should probably be 
> added to the docs (assuming it's not already there).
>
> Leo, would you like to do a pull request?
>
> On Nov 5, 2014, at 8:24 PM, Mark Koudritsky  wrote:
>
> > Variables should to be provided when adding the plugin
> > E.g:
> >
> >cordova plugin add org.some.plugin --variable API_KEY=some_value
> >
> > Example of a plugin that uses variables:
> > http://plugins.cordova.io/#/package/com.phonegap.plugins.facebookcon
> > ne
> > ct
> >
> > Relevant places in the code in cordova-lib:
> >   Where variables are checked during plugin add:
> >
> > https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/co
> > rd
> > ova/plugin.js#L126
> >
> > https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/pl
> > ug
> > man/install.js#L296
> >
> > Here each variable is replaced with its value when generating the 
> > "config munge" which is an object that describes changes that need 
> > to be applied to the platform dir.
> >
> > https://github.com/apache/cordova-lib/blob/master/cordova-lib/s

RE: Questions re: plugin variables

[Horn, Julian C]

Leo's question really hasn't been answered yet.  Let me try to make this more 
concrete and see if anyone can explain whether the current behavior of the CLI 
is correct or not.

The plugin.xml in the StatusBar plugin contains the following content:

...

.
  ...
  

There are several mysteries here.

1) What does it mean if the name attribute of a preference tag does not obey 
the "only capital letters, digits, or underscores" rule?  Apparently it can 
never cause variable replacement.
2) What does the value attribute mean?  Does this supply a default value for a 
variable if the variable is not mentioned in the --variable flag (thus making 
the variable "optional")?
3) Where can  tags legally appear?  Must they be outside of 
 tags, or can they be inside  tags or even inside 
 tags?

Our experiments with CLI 4.0.1-dev show the following:

1) The value attribute is ignored by the CLI, or at least it doesn't create a 
default value.

For example, suppose you put the following preference tag outside of any 
 tag.

We found that the user is still required to supply --variable API_KEY, which 
means that "my-api-key" never becomes the value of API_KEY.

2)  tags appear to be ignored by the CLI if they appear below a 
 node.

If you move the  node shown above from outside a  node to 
inside a  node, then the CLI stops prompting for a --variable flag 
and $API_KEY is not replaced by anything.

It looks to us like the  tag is overloaded.  When it appears 
outside the  tag it defines a variable.  When it appears inside a 
 tag it does not.  The meaning of the  tag within a 
 tag is apparently determined by the platform.

If people agree that this is correct then the documentation can be updated 
accordingly.  However, we did see some code in the implementation that seemed 
to be looking for  tags inside of  tags.  It seems like 
this isn't working as intended, but then again we can't figure out what the 
intention is.

Julian

-Original Message-
From: Marcel Kinard [mailto:cmarc...@gmail.com] 
Sent: Friday, November 07, 2014 9:42 AM
To: dev@cordova.apache.org
Subject: Re: Questions re: plugin variables

If there is a reasonable question from a user, it should probably be added to 
the docs (assuming it's not already there).

Leo, would you like to do a pull request?

On Nov 5, 2014, at 8:24 PM, Mark Koudritsky  wrote:

> Variables should to be provided when adding the plugin
> E.g:
> 
>cordova plugin add org.some.plugin --variable API_KEY=some_value
> 
> Example of a plugin that uses variables:
> http://plugins.cordova.io/#/package/com.phonegap.plugins.facebookconne
> ct
> 
> Relevant places in the code in cordova-lib:
>   Where variables are checked during plugin add:
> 
> https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cord
> ova/plugin.js#L126
> 
> https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plug
> man/install.js#L296
> 
> Here each variable is replaced with its value when generating the 
> "config munge" which is an object that describes changes that need to 
> be applied to the platform dir.
> 
> https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plug
> man/util/config-changes.js#L368
> 
> 
> On Wed, Nov 5, 2014 at 5:28 PM, Treggiari, Leo 
> 
> wrote:
> 
>> I'm having a hard time understanding exactly how plugin variables work.
>> It's probably a level of detail that only plugin developers and tool 
>> developers need to be concerned about.  I'd appreciate it if someone 
>> can give me the answers.
>> 
>> 1.  "variables can be indicated by a dollar-sign followed by a series 
>> of capital letters, digits, or underscores."
>> "To make the variable mandatory, the  tag needs to 
>> contain a  tag."
>> Does this mean that there are optional and required variables - i.e?
>>  -  A variable reference is defined by a lexical element which 
>> begins with a $ and is followed only by capital letters, digits, or 
>> underscores?
>>  -  A variable is made mandatory by the presence of a 
>>  tag which uses the same name with the $ removed?
>>  -  Can this  tag be anywhere in the plugin.xml file, 
>> or must it be the direct child of the  element or
>> a  element?
>>  -  Can the variable references be anywhere or only within strings?
>> 
>> 2.  Where and when are the variables replaced by their value?
>>  -  plugin.xml is the only place that the variable value is used 
>> and only for replacing the variable references?
>>  -  When in Cordova CLI do the values get applied - during "add", 
>> during "prepare"?
>> 
>> 3.   What happens if you combine dependencies with variables.  For
>> example, suppose A depends on B, and B requires a variable X.  How do 
>> you supply the value?
>> 
>> Thanks,
>> Leo
>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.or

RE: Summarizing thoughts on cordova-browser vs Ripple

[Horn, Julian C]

I'd like to introduce myself and put in my two cents here. My name is Julian 
Horn.  I work for Intel on the XDK, an integrated development environment for 
cross-platform HTML5 applications.  I am the team lead for the Device Emulator 
component, which is our Ripple derivative.  My background is mostly in software 
development tools: compilers, debuggers, simulators and analysis tools. I have 
been working with the Ripple code base for a couple of years now.  

If I'm understanding the cordova-browser concept, the implementation of a 
Cordova API for the browser platform should consist of code that bridges 
between the platform-independent Cordova API and whatever equivalent is 
available in the current browser session.  For example, the camera API 
getPicture function would invoke the getUserMedia API, which is the closest 
thing we have to a W3C standard way to take a picture.  If the browser doesn't 
implement this API or the host system doesn't have a camera, then the 
getPicture call fails with "camera unavailable".

This seems like a fine way to gradually migrate from packaged apps that rely on 
native code plugins to pure web apps that rely on the browser to access mobile 
device resources.  This should work great when you have a browser-portable 
implementation.  It may be a challenge with some plugins, since of course 
Cordova/PhoneGap was designed to cover gaps in browser support.  But at least 
we don't have to wait for a real W3C standard to be agreed.

The goal of our XDK product is to facilitate development of cross-platform 
mobile HTML5 applications.  We see the Device Emulator (our Ripple) as enabling 
developers to test an HTML5 mobile application on the host system.  While this 
is no substitute for testing on real hardware, the Device Emulator does offers 
some advantages that can accelerate the development process.  To summarize 
quickly:
 * It’s really fast.
 * You don't need an array of mobile devices.
 * You can put off dealing with weird target system quirks until after you get 
your basic application logic debugged.
 * You get full native JavaScript debugging, which is faster, simpler, and more 
available than remote debug.
 * You can create testing situations that are difficult or impossible to create 
in real life, such as GPS timeout.
 * It's a great teaching tool.
 * It allows you to prototype quickly.
 
Assuming the functionality delivered by Ripple has value (and we find it does), 
one needs a way to reconcile this with the cordova-browser effort.  Here's how 
I see that working out.

One idea is to rely on the browser developer tools to supply emulation support 
and just drop Ripple.  I don't like this much.  Today the developer tools 
emulation UI is fairly primitive, but of course, there is nothing stopping the 
browser vendors from building all the functionality in the Ripple Geolocation 
panel (or indeed all of Ripple) into the developer tools.  The bigger problem 
from my point of view is that this is a closed system.  There's no way for a 
non-browser-vendor to extend the browser to provide emulation support for new 
plugin APIs.

The alternative is to do a "cordova prepare browser" and load the results into 
Ripple.  Assuming the browser platform code follows the usual pattern, that is, 
that it goes through an exec/execProxy layer, it should be possible for Ripple 
to intercept at that level.  Ripple can delegate to the execProxy 
implementation if it has no emulation-time implementation of its own.  This 
means that unrecognized APIs run unaltered, in which case you get whatever 
behavior you get on the browser platform.  This is a really exciting prospect.  
It's way better than that "we don't know what to do" dialog that Ripple puts up 
when an exec layer function it doesn't recognize is called.

In fact there are some Cordova APIs that Ripple implements by mostly delegating 
to a Chrome-specific API.  For example, the simulation of the Cordova File API 
is based on webkitRequestFileSystem.  (Unfortunately no other browser vendors 
have seen fit to support this API.)  In those cases I think the Ripple 
implementation of the API is likely to coincide nicely with the browser 
platform implementation.

Unlike ripple-as-a-platform, this model doesn't allow plugin authors to provide 
their own emulation-time solutions.  I was always skeptical that many plugin 
authors would really do this (others disagree).  But if they at least provide a 
browser implementation then Ripple has something to fall back on.  And if 
there's something better that can be done, we can always extend Ripple.

Julian

-Original Message-
From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panar...@microsoft.com] 
Sent: Wednesday, November 05, 2014 2:25 PM
To: dev@cordova.apache.org
Subject: RE: Summarizing thoughts on cordova-browser vs Ripple

MSOpenTech is currently working on porting our ripple-platform prototype - 
https://github.com/MSOpenTech/cordova-ripple to work on top of c

[Discuss] Ripple as a platform

[Horn, Julian C]

I'd like to get feedback from the mailing list about the basic concept of 
Ripple as a platform, not just on the prototype described in earlier mail from 
Parashuram Narasimhan (MS OPEN TECH).  For information about the prototype, see 
his mail of 7/22/2014 titled RE: [Discuss] The Future of Ripple as a Top Level 
ASF Project (and subsequent 
replies).



The underlying idea of the prototype, as I see it, is to use the plugin.xml 
format to describe additional files that would be used for emulation of that 
plugin.  The prototype CLI treats ripple as a platform that is a peer to the 
other platforms, such as android, windows8, ios and so on.  The idea is to use 
the CLI "cordova prepare ripple" command to create sources that are suitable 
for use with Ripple.



The question this raises for me is whether Ripple is best thought of as one 
platform or as a set of platforms, one for each real platform.  In other words, 
instead of preparing and emulating "ripple" code, maybe Ripple should emulate 
"ripple-ios" code when emulating an iOS device, "ripple-android" code when 
emulating an android device and so on.  The Ripple Cordova 3 support added by 
Gord Tanner follows this model.



One can imagine a different prototype that uses the same style of plugin.xml 
file but makes different CLI changes.  Instead of ripple being another 
user-visible platform, it could just be a command line switch, as in "cordova 
prepare windows8 --emulate ripple".  This would tell the CLI to combine the 
contribution of both the windows8 and ripple platforms in the prepare output.



It's obviously simpler to treat ripple as one platform.  The downside is that 
it makes it impossible to emulate platform-specific source differences.



Platform-specific source differences can arise in two ways.  The "contact list" 
plugin for example provides functions that only exist on iOS.  These functions 
are defined in a JavaScript file you only get when you prepare for ios. 
Platform-specific source differences can also arise from the "merges" folder.  
This allows an application developer to supply different files on different 
platforms. If Ripple is multiple platforms, then the user can test with the 
sources that would actually be used on the selected device.  If Ripple is one 
platform, then the user must test with one code base for all devices.  The 
plugin author decides what the sources Ripple will use for the plugin, and the 
application author decides what merge sources will be used.



At Intel we have discussed the one-versus-many question but no clear consensus 
has emerged. I think it boils down to an interesting philosophical question 
about what Ripple is or should be trying to be.



Ripple is obvious incapable of emulating many kinds of platform-specific 
differences.  After all, Ripple executes the program under test in the host 
system web runtime, not the target system web runtime found on a mobile device. 
 Typically the host system web runtime is newer and more capable than the 
mobile counterparts.  Code often works under emulation yet fails or behaves 
differently on real hardware. Some argue that this proves that Ripple should 
not be thought of as an impersonation of real devices, but rather as a kind of 
pseudo-device that doesn't pretend to resemble any real device.  They see the 
present product as misleading and confusing. Others argue that Ripple should 
try to imitate a real device as best it can, given the limitations of its 
technical approach.  They see Ripple like an instruction level simulator that 
is fast but not cycle-accurate: limited accuracy but useful nevertheless.



So what do you think?  Is Ripple a device impersonator with limitations, or is 
it more like its own kind of device?  Should Ripple be its own platform, or 
should it be many platforms?