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
-----Original Message-----
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Friday, November 14, 2014 4:07 AM
To: dev
Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
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.
var div = ... createUI;
ripple.registerPluginUi(div)
Still also seems powerful though, to have Ripple be able to add UI for plugins
that don't provide their own.
On Mon, Nov 10, 2014 at 3:48 PM, Michal Mocny <mmo...@chromium.org> wrote:
> On Thu, Nov 6, 2014 at 6:52 PM, Horn, Julian C
> <julian.c.h...@intel.com>
> wrote:
>
> > I'd like to introduce myself and put in my two cents here. My name
> > is Julian Horn. I work for Intel on the XDK, an integrated
> > development environment for cross-platform HTML5 applications. I am
> > the team lead
> for
> > the Device Emulator component, which is our Ripple derivative. My
> > background is mostly in software development tools: compilers,
> > debuggers, simulators and analysis tools. I have been working with
> > the Ripple code base for a couple of years now.
> >
> > If I'm understanding the cordova-browser concept, the implementation
> > of a Cordova API for the browser platform should consist of code
> > that bridges between the platform-independent Cordova API and
> > whatever equivalent is available in the current browser session.
> > For example, the camera API getPicture function would invoke the
> > getUserMedia API, which is the
> closest
> > thing we have to a W3C standard way to take a picture. If the
> > browser doesn't implement this API or the host system doesn't have a
> > camera, then the getPicture call fails with "camera unavailable".
> >
> > This seems like a fine way to gradually migrate from packaged apps
> > that rely on native code plugins to pure web apps that rely on the
> > browser to access mobile device resources. This should work great
> > when you have a browser-portable implementation. It may be a
> > challenge with some
> plugins,
> > since of course Cordova/PhoneGap was designed to cover gaps in
> > browser support. But at least we don't have to wait for a real W3C
> > standard to
> be
> > agreed.
> >
> > The goal of our XDK product is to facilitate development of
> cross-platform
> > mobile HTML5 applications. We see the Device Emulator (our Ripple)
> > as enabling developers to test an HTML5 mobile application on the
> > host system. While this is no substitute for testing on real
> > hardware, the Device Emulator does offers some advantages that can
> > accelerate the development process. To summarize quickly:
> > * It’s really fast.
> > * You don't need an array of mobile devices.
> > * You can put off dealing with weird target system quirks until
> > after
> you
> > get your basic application logic debugged.
> > * You get full native JavaScript debugging, which is faster,
> > simpler,
> and
> > more available than remote debug.
> > * You can create testing situations that are difficult or
> > impossible to create in real life, such as GPS timeout.
> > * It's a great teaching tool.
> > * It allows you to prototype quickly.
> >
> > Assuming the functionality delivered by Ripple has value (and we
> > find it does), one needs a way to reconcile this with the cordova-browser
> > effort.
> > Here's how I see that working out.
> >
> > One idea is to rely on the browser developer tools to supply
> > emulation support and just drop Ripple. I don't like this much.
> > Today the
> developer
> > tools emulation UI is fairly primitive, but of course, there is
> > nothing stopping the browser vendors from building all the
> > functionality in the Ripple Geolocation panel (or indeed all of
> > Ripple) into the developer tools. The bigger problem from my point
> > of view is that this is a closed system. There's no way for a
> > non-browser-vendor to extend the browser to provide emulation support for
> > new plugin APIs.
> >
> > The alternative is to do a "cordova prepare browser" and load the
> > results into Ripple.
>
>
> This would be my preference if at all possible. Specifically, I think
> ripple would move much faster and be better architected if it didn't
> have to depend on making changes directly to cordova. Though it
> should be acceptable to create a ripple platform (cordova run ripple)
> if really need be.
>
>
> > Assuming the browser platform code follows the usual pattern, that
> > is, that it goes through an exec/execProxy layer, it should be
> > possible for Ripple to intercept at that level. Ripple can delegate
> > to the execProxy implementation if it has no emulation-time implementation
> > of its own.
> This
> > means that unrecognized APIs run unaltered, in which case you get
> whatever
> > behavior you get on the browser platform. This is a really exciting
> > prospect. It's way better than that "we don't know what to do"
> > dialog
> that
> > Ripple puts up when an exec layer function it doesn't recognize is
> called.
> >
>
> Thats interesting. I hadn't considered doing it this way, but it
> actually sounds like a great solution.
>
>
> >
> > In fact there are some Cordova APIs that Ripple implements by mostly
> > delegating to a Chrome-specific API. For example, the simulation of
> > the Cordova File API is based on webkitRequestFileSystem.
> > (Unfortunately no other browser vendors have seen fit to support
> > this API.) In those
> cases I
> > think the Ripple implementation of the API is likely to coincide
> > nicely with the browser platform implementation.
> >
> > Unlike ripple-as-a-platform, this model doesn't allow plugin authors
> > to provide their own emulation-time solutions. I was always
> > skeptical that many plugin authors would really do this (others
> > disagree). But if they
> at
> > least provide a browser implementation then Ripple has something to
> > fall back on. And if there's something better that can be done, we
> > can always extend Ripple.
> >
>
> Given that the biggest benefit of Ripple is to provide UI to dig into
> and manually adjust the plugin behaviour, I share your sentiment. I
> did voice that I thought plugin authors would provide implementations
> -- but that is for what we know are classifying as cordova-browser
> implementations (even if just stubs / no-ops).
>
>
> >
> > Julian
> >
> > -----Original Message-----
> > From: Parashuram Narasimhan (MS OPEN TECH) [mailto:
> panar...@microsoft.com]
> > Sent: Wednesday, November 05, 2014 2:25 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
> >
> > MSOpenTech is currently working on porting our ripple-platform
> > prototype
> -
> > https://github.com/MSOpenTech/cordova-ripple to work on top of
> > cordova-browser. The question on how each plugin exposes a UI to
> > provide mock data is still up for discussion, but Intel has a lot of
> > context on that area.
> >
> > -----Original Message-----
> > From: Kirupa Chinnathambi [mailto:kiru...@microsoft.com]
> > Sent: Wednesday, November 5, 2014 11:04 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
> >
> > +1 to what you’ve both stated.
> >
> > 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 browser. Simulating plug-in behavior would be external to that
> > in some
> form
> > or fashion.
> >
> > Cheers,
> > Kirupa
> >
> > -----Original Message-----
> > From: mikeywbro...@gmail.com [mailto:mikeywbro...@gmail.com] On
> > Behalf
> Of
> > Michael Brooks
> > Sent: Wednesday, November 5, 2014 9:22 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
> >
> > >
> > > In my view, ripple should be built on top of the browser platform
> > > work, and ideally also decouple the UI from the plugin
> > > instrumentation, but thats up to the folks running that effort.
> >
> >
> >
> >
> > > With all this in mind, I think the cordova-browser effort should
> > > proceed with current direction, but keep in mind that more
> > > advanced plugin instrumentation doesn't belong there.
> >
> >
> > This echo's my views on the Browser Platform and Ripple as well.
> >
> > Ideally, the Browser Platform is a production deployment environment
> > for the web, while Ripple is debugging instrumentation that runs on
> > the
> Browser
> > Platform.
> >
> > On Wed, Nov 5, 2014 at 8:04 AM, Michal Mocny <mmo...@google.com> wrote:
> >
> > > We debated a bit about browser vs ripple at phonegap day
> > > (especially Intel folks who have done lots of work here), and the
> > > my personal tldr; is that there is in fact a home for both.
> > >
> > > 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.
> > >
> > > Some of the work ripple has done traditionally can now in fact
> > > just be done via browser DevTools, but their are still some cases
> > > where custom hooks into plugins are the best way to provide a good
> > > local "simulator". (Chrome DevTools at least now provide mobile
> > > emulation,
> > unsure about others).
> > >
> > > In my view, ripple should be built on top of the browser platform
> > > work, and ideally also decouple the UI from the plugin
> > > instrumentation, but thats up to the folks running that effort.
> > >
> > > With all this in mind, I think the cordova-browser effort should
> > > proceed with current direction, but keep in mind that more
> > > advanced plugin instrumentation doesn't belong there.
> > >
> > > -Michal
> > >
> >
>
