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. 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.
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.
Julian
-----Original Message-----
From: Parashuram Narasimhan (MS OPEN TECH) [mailto:[email protected]]
Sent: Wednesday, November 05, 2014 2:25 PM
To: [email protected]
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:[email protected]]
Sent: Wednesday, November 5, 2014 11:04 AM
To: [email protected]
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: [email protected] [mailto:[email protected]] On Behalf Of
Michael Brooks
Sent: Wednesday, November 5, 2014 9:22 AM
To: [email protected]
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 <[email protected]> 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
>
