cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Horn, Julian C" <julian.c.h...@intel.com>
Subject [Discuss] Ripple as a platform
Date Fri, 08 Aug 2014 14:13:00 GMT
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?




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