+1 to what Kirupa said The idea here would be to have a secondary workflow for the browser platform that would include the necessary metadata for mock plugin functionality. Ideally: the mock behavior is implemented/provided by the pluginplugins provide optional model-based UI for controlling/simulating the mock plugin functionalitySomething like http://www.w3.org/2011/mbui/browser dev tools/IDE tools/browser extensions implement the model-based UI for plugin simulation I am still at early stages of my design thoughts. Love to hear what others are thinking about. - ali
> From: panar...@microsoft.com > To: dev@cordova.apache.org > Subject: RE: Summarizing thoughts on cordova-browser vs Ripple > Date: Wed, 5 Nov 2014 19:24:44 +0000 > > �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 > > > �Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���âFWb�V�7V'67&�&T6�&F�f�6�R��&pФf�"FF�F����6����G2�R���âFWbֆV�6�&F�f�6�R��&p
