Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.219.47 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <FFD143336FEF2D41AFA4D9CE7E119BA145E9528A@FMSMSX112.amr.corp.intel.com>
References: 
 <FFD143336FEF2D41AFA4D9CE7E119BA145E9528A@FMSMSX112.amr.corp.intel.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Fri, 8 Aug 2014 10:47:29 -0400
Message-ID: 
 <CABiQX1VNXrMzBtDowSDDf5T3YXmyV4tXBiU_xbDngXT71zBOFg@mail.gmail.com>
Subject: Re: [Discuss] Ripple as a platform
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2f2660c141e05001f4a87

--001a11c2f2660c141e05001f4a87
Content-Type: text/plain; charset=UTF-8

I think this is a nice summary of the trade-offs between the two
approaches.

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
environment.


On Fri, Aug 8, 2014 at 10:13 AM, Horn, Julian C <julian.c.horn@intel.com>
wrote:

> 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<
> http://markmail.org/message/jdngxmy4nitg4pl6> (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?
>
>
>
>

--001a11c2f2660c141e05001f4a87--