ripple-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Horn, Julian C" <>
Subject RE: Results from recent Ripple & Cordova-Browser meeting
Date Tue, 25 Nov 2014 22:21:55 GMT
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  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.


-----Original Message-----
From: Parashuram Narasimhan (MS OPEN TECH) [] 
Sent: Tuesday, November 25, 2014 2:03 PM
Subject: RE: Results from recent Ripple & Cordova-Browser meeting


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. 


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 -

-----Original Message-----
From: Michal Mocny [] 
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"
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

Any other conclusions from the meeting?

View raw message