cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Camden <>
Subject Re: Summarizing thoughts on cordova-browser vs Ripple
Date Fri, 14 Nov 2014 21:23:10 GMT
I¹m pretty late to responding to this thread, but I wanted to throw in a
few comments. In the first msg, Michal Mocny said this:

"Basically, browser-platform is for getting apps running in a browser (duh)
with as much working functionality as possible.  Its supposed to simplify
the 'if cordova then dialog else alert' problem, so you can build even more
of your app with just local development.  Seemingly this could be used to
make targeting both web and app even easier.

Ripple is for instrumenting/debugging apps by manipulating plugins.  Its
about having a UI that reaches into geolocation or camera and controls what
the plugin returns to the app.  Its about re-running the same device events
over and over for tracking application logic changes.²

I could not disagree with the second part more. I can tell you that from
my experience, the casual end user/PG developer did not see Ripple as any
different from what you described in the first paragraph. Maybe I¹m not
reading you right, but I honestly don¹t think most users of Ripple saw it
as anything but a way to test your code in the browser.

Michael Brooks said:
"Ideally, the Browser Platform is a production deployment environment for
the web, while Ripple is debugging instrumentation that runs on the Browser

Again, I just don¹t see this. ³Production deployment²? As in - it is used
by the public? I don¹t think our users will see that. I don¹t want the
public to use my PG/Cordova app in the browser. I, the developer, want to
use the browser just because it is quicker and the debugging tool is

Kirupa said:
"Cordova-browser shouldn't be responsible for providing mock data, UI, or
any additional functionality for simulating a plug-in. It¹s primary goal
is to (as you both mention) be responsible for getting apps to run in the

I love Ripple, butŠ
It was dead for a *very* long time. It has come back, and there is
activity, but I¹m not convinced it will carry on. (Don¹t get me wrong, I
want it to!) BAAP (I¹m using that for Browser As A Platform, much easier
to type ;) is baked into Cordova and ³just plain works² once a plugin
author adds support. It isn¹t an external tool - it is part of the core
functionality. I think then that if it makes sense for a plugin to do UI,
then BAAP should do it. I see no reason not too. Since the only one seeing
it is the developer, then this UI, or mock data, can be simple and direct.
If it lets me run my app quickly in the browser, then it doesn¹t have to
be production-ready, just dev-ready.

Andrew said:
"From reading this, seems like it could work well to have plugins provide
both browser and ripple implementations. They could make them the same, or
have the ripple one provide some sort of nice emulation UI. e.g.²

I see that as unlikely myself. If I were to write a plugin (I¹ll be
honest, I haven¹t yet), I can¹t imagine doing the same thing twice for
both, especially with how little movement has been done in Ripple. As a
feature, isn¹t it fair to say BAAP is ³done²? I mean it needs support from
more plugins, but as a feature, it is complete. I don¹t have to worry
about it not working in the future as Ripple did.

On 11/14/14, 12:38 PM, "Horn, Julian C" <> wrote:

>Yes, that's absolutely right.  The ripple and browser platforms can
>coexist, and you can refer to the API implementations in the
>cordova-browser platform from the ripple platform.
>You can imagine how this would work.  The exec call should land in the
>ripple implementation of the API.  That code can decide whether it needs
>to delegate to the browser implementation of the API.  (It could use UI
>to guide this decision.) If so, it finds the browser implementation via
>execProxy and invokes it.
>This is easy when the ripple implementation is built in.  Ripple's
>implementation of "exec" separates the Services registered with Ripple
>from those that self-register with execProxy. Ripple therefore can prefer
>its own implementation when both exist. When the ripple and browser
>implementations are both in the same plugin then you have a conflict
>because both of them want to self-register as the same service.  Still,
>I'm confident that this can be sorted out.
>For example, say the JS part of a plugin calls exec for service S,
>function F.  The browser implementation self-registers with execProxy as
>S.  The ripple implementation could self-register as "Ripple S".  When
>asked to invoke a function in service "S", the Ripple exec function can
>look for the object registered as "Ripple S" before looking for the
>object registered as "S".  Easy.
>    Julian

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message