Hi Michal, I'll take a crack at your second question, "why is Ripple a platform which you 'cordova prepare' for". I included a quick answer to that question in reply to Jesse's question, but I can see that was a bit too terse. I'll try to explain in more detail how I look at this.
Ripple must emulate prepared sources for some platform. At first blush seems best to prepare for the platform corresponding to the currently selected device. This is in fact what the (unreleased) Ripple sources do today, and it is also what the Intel XDK Device Emulator does. In particular, this handles the following two concerns: 1) The JavaScript source for the user project isn't identical on different platforms if you have "merges". 2) The JavaScript source for plugins isn't always identical on different platforms. For example, the contact list plugin has some functions that only exist on iOS. The ripple platform, as first proposed, offers an alternative model, which is to prepare for the "ripple" platform. The idea here is to embed the emulation-time implementation used by Ripple as the native code for the "ripple" platform. Among other virtues, this allows plugin authors to augment the capabilities of Ripple without releasing a new Ripple version. This is an attractive option in a world where plugins grow like crazy and we haven't had regular Ripple releases. On August 8, when the ripple platform was first proposed, I posted a note to this mailing list and [email protected]. I pointed out that preparing for the ripple platform doesn't get the right answer in the two cases described above. I asked whether it might be better to prepare for some kind of hybrid platform like "ripple-ios". I had in mind that "cordova prepare XXX --emulate ripple" could take JS from the XXX platform but native code from the ripple platform. This is based on the concept that Ripple is not one platform, but several. Since then the browser platform has emerged, and there is some overlap between the browser platform and what we had been calling the ripple platform, as I described in my foils. At the meeting I brought up the idea of a kind of hybrid platform prepare, but this time with "cordova prepare browser --emulate" meaning take the union of the browser and ripple platforms. This makes sense because ripple generally would want to reuse the browser platform sources. It eliminates the maintenance work of keeping the ripple and browser platforms in sync. People liked that idea. I suppose one could try to combine the two ideas and imagine a form of prepare that takes the JS layer from the platform for the current emulation device, and the native layer from the union of the browser and ripple platforms. But I'm inclined to stop here. I hope that answered your question. Julian -----Original Message----- From: Parashuram Narasimhan (MS OPEN TECH) [mailto:[email protected]] Sent: Tuesday, November 25, 2014 2:03 PM To: [email protected] Subject: RE: Results from recent Ripple & Cordova-Browser meeting Hi, Here is something we put together, illustrating how Ripple and Cordova-browser can work together. We have tried to summarize the many comments that this topic has seen on the Cordova mailing list, and the Ripple mailing list. PPT http://1drv.ms/1xP6bbI PDF http://1drv.ms/11ruAY9 For next steps, I think it may make sense to have a hangout meeting since most folks could not make it to the last meeting. Here is a Doodle I created. If all the folks interested in this could add in the preferred times, I can set up the meeting - http://doodle.com/7x5dfmrzmz64tmgp -----Original Message----- From: Michal Mocny [mailto:[email protected]] Sent: Tuesday, November 25, 2014 8:42 AM To: Ripple Dev List [ASF]; Horn, Julian C Subject: Results from recent Ripple & Cordova-Browser meeting (Re-post from a previous thread) Hi Julian, I missed the meeting, but I agree with your slides and conclusions. A few minor comments: 1. I'm happy enough to label cordova-browser as a "deployment" platform, but we should expect that it will have usefulness outside of actual deployment to users. I really like labeling of Ripple as a "diagnostics" platform. 2. I'm a little unclear why Ripple is a platform (which you `cordova prepare` for), rather than just an run/emulate target? Wouldn't you want to run the cordova-ios assets for ios diagnostics, cordova-android target for android diagnostics, etc? (Jesse brought this question up on the dev lists) Any other conclusions from the meeting? Thanks -Michal
