On Mon, Nov 17, 2014 at 6:37 AM, Ray Camden <rayca...@adobe.com> wrote:
> > > On 11/15/14, 2:17 PM, "Michal Mocny" <mmo...@chromium.org> wrote: > > >Ray, I think (hope) you are slightly misreading the distinction. Trying > >to > >rephrase: > > > >Ripple is an (optional) tool for mobile-device-emulation. It just happens > >to be implemented in a browser, and yes has historically been used by devs > >to run cordova apps locally in a browser. But ripple does a lot more than > >some devs need/want. We want to take all those extras out for > >cordova-browser, and leave them in for Ripple. > > I disagree completely. ³just so happens to be implemented in a browser² > makes it sound like a random thing. Ripple was a way to make use of the > speed of a browser to run my PG/Cordova apps while Œfaking¹ stuff like > camera and GPS. It let me focus on the non-Cordova stuff, like random APIs > (especially since it lets me bypass the remote XHR restriction w/o CORS). > > >Specifically, cordova-browser would provide a minimum valid cordova > >environment & plugin browser shims, just so your app loads without errors > >in a browser. There would not be any specific mobile device or platform > >emulation. Many devs do this manually today (Adobe even presented on this > >topic at PGDay), but cordova-browser will automate some of the work now. > > > And I strongly vote against this. The fact that I can fake camera w/ BAAP > now and not rely on Ripple, which again was dead for like a *year*, is a > huge big deal to me, and I¹d argue others as well. > > It sounds like we are saying we should take BAAP, which has the beginnings > of a good Ripple replacement, and neuter it, which I think would be > horrible. > Not at all. What is it you think we are proposing? I'm merely suggesting that the cordova-browser camera plugin implementation shouldn't *also* come with a DOM component that sits over top of your application to manipulate the camera. The existing BAAP camera implementation is great as currently implemented, and wouldn't change. Another example would better illustrate the difference: BAAP geolocation shim I believe should just use the browser geolocation api, or return a single fixed location if that isn't available. It needn't support programmatically / UI for manipulating custom location, which Ripple geolocation does. > > > > >What you do with the browser targeted version of your application is up to > >you. Some developers won't use it at all, others may use it for rapid > >development on a subset of the app, while others may use it to actually > >publically host for the mobile web. I'm not necessarily sure if that last > >point is a great idea, but I'm convinced we shouldn't get in the way of > >others trying. (Ray, if you don't want the public to use your app from a > >browser, just don't host it, that will be your call to make). > > I guess this is the main sticking point then. It sounds like you are > saying we should support browser as a complete platform, and having the > plugins do too much will be a problem. I think there is a chance folks may > want BAAP to be used publicly, but I think a good debugging alternative > would be *much more* desired. > I previously used this argument as well, but didn't have concrete examples of where optionally targeting prod harmed creating a good debugging alternative. I agree that a good debugging env is the more important goal, though not the only one. If there are valid examples where these goals are at odds, we need to surface them. > > As an example, I¹ve got an app now which uses barcode scanning for one > small part. By adding the Browser platform to the plugin, I am able to do > all of my work in the browser now and fake a barcode when I need it. That > is a problem that - imo - is much more valuable than supporting browser as > a destination of my app. > If you just want to return a single fixed barcode, I agree BAAP should do this. If you want to be able to customize the barcode at runtime, with a simple UI that is automatically injected into your page as part of the runtime, then I think that is a task for Ripple (or other emulators). > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
