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 > > >
