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