cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: [Discuss] Ripple as a platform
Date Fri, 08 Aug 2014 14:47:29 GMT
I think this is a nice summary of the trade-offs between the two

I'm much in favour of ripple as a single platform, mainly because of the
fact that you're not running it on devices. The merges/ problem can be
solved by the user adding a "ripple" dir to merges, and the per-platform
differences of plugins is only one of *many* subtle differences you'll find
when you're running on a desktop browser vs. the actual mobile host

On Fri, Aug 8, 2014 at 10:13 AM, 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?

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