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.h...@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? > > > >
