Shouldn't ripple be able to emulate/monkey-patch any of the platforms? If I am looking at and testing my cordova-ios app in ripple, I think I would want the cordova-ios.js to be run, and not cordova-browser.js, otherwise there could be latent issues that I would never see until I actually ran it on the device, or emulator. Hopefully the differences between each platform's cordova.js is insignificant, but I don't think that we know this for sure.
The code to inject/intercept ANY platform's cordova.exec is simple, really, it is <10 lines. In my mind, ripple should be responsible for hooking it's own way in, and proxying, without extra specific built in support either by cordova-browser, or cordova-js. @purplecabbage risingj.com On Tue, Nov 18, 2014 at 11:49 AM, Michal Mocny <mmo...@chromium.org> wrote: > Serge, > > That sounds like you disagree with Julian's earlier summary that Ripple > should just intersect at the exec proxy level, and propose instead that > Ripple should intersect by having "hooks" inside the cordova-browser plugin > js-modules, correct? > > I think thats not impossible (plugin authors can do what they want), but > perhaps should just happen on a case-by-case basis, as required. If you > have ideas about an architecture that we should advise developers to use by > default, I'm curious what that would even look like. > > -Michal > > On Tue, Nov 18, 2014 at 1:01 PM, Lunev, Serge <serge.lu...@intel.com> > wrote: > > > Let me add two pennies from my side also then :) > > > > From the community perspective, I have little hope that a random plugin > > author will care about anything beyond browser target for his/her plugin > > for testing/debug purposes. I do think though that putting a right > > architecture in place for something better than a regular browser target > > can provide is important. 'Something better' means here a way to hook up > > browser developer tools (or Ripple / node-webkit combo in Intel XDK case) > > to control plugin behavior so that input data could be controlled by > > appropriate UI in browser/XDK. > > > > For us in XDK the alternative would be to fully separate a plugin from > its > > emulation. I.e. if we choose to support certain plugin emulation in the > > XDK, that will be totally technically separate from its Cordova > > implementation. While this is a viable alternative, this just doesn't > smell > > right. > > > > Best, > > Serge Lunev > > Intel XDK Engineering Manager > > @lunarserge > > > > -----Original Message----- > > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf > Of > > Brian LeRoux > > Sent: Tuesday, November 18, 2014 9:26 AM > > To: dev@cordova.apache.org > > Subject: Re: Summarizing thoughts on cordova-browser vs Ripple > > > > I'm less interested in copying work being done faster/better in the > > browser devtools. Certainly some UI abstractions are helpful (map > controls, > > acceleromter scrubbing widget, etc) but the returns for dev time are > > diminishing for the effort to author/maintain. Esp bad considering we'd > > have to pick UI paradigms and enforce them somehow. > > > > For my two pennies, providing an abstraction that allows authoring time > > convenience of using browser with an eventual goal for open web > publishing > > would be the best architecture (and strategy) for Cordova to pursue. > > > > On Tue, Nov 18, 2014 at 9:12 AM, Michal Mocny <mmo...@chromium.org> > wrote: > > > > > On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden <rayca...@adobe.com> > wrote: > > > > > > > > > > > >> > > > > >> On 11/15/14, 2:17 PM, "Michal Mocny" <mmo...@chromium.org> wrote: > > > > >> > > > > > > > > >>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. > > > > > > > > I’m with you on that - but I think that is an example that works > > > > well w/o UI and other plugins may not. Let’s consider contacts, > > > > specifically pickContact. I *would* be ok with a UI of some sort, > > > > perhaps just 3 > > > simple > > > > contacts in a list, that that user can select. In theory it could > > > > also just automatically fire contactSuccess, but my point is that > > > > I’m not opposed to it providing a bit of UI as well. > > > > > > > > > > > > >>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). > > > > > > > > > > > > So I think this is the crux of our disagreement then. :) Right now > > > > the plugin (and I wrote this, so I may be biased ;) uses a prompt so > > > > you can enter a code. My thinking there was if you didn’t care, you > > > > would type 1 and hit enter, but if you were passing the bar code to > > > > some service, you could paste something in. To me, that’s more > > > > useful then just using a > > > hard > > > > coded value you can’t tweak. I think that usefulness outweighs the > > > > potential ‘loss’ of being able to run this as a real web app. > > > > > > > > > > Fair enough. Sounds like you want some of what I've proposed Ripple > > > could offer, but are concerned that Ripple won't be a > > > viable/sustainable choice for you. To be honest, I share that concern. > > > > > > For the barcode scanning example, I think a popup with an input box is > > > fine, even for prod, so long as the popup is presented as if to a user > > > and not as if to a developer. Hopefully we can improve it to also > > > offer an input type=image, or to use the webcam (I haven't looked, not > > > sure if it does this yet). > > > > > > If we really want separate dev mode and prod mode for a given plugin, > > > perhaps we can just add an api for toggle this. I just hope to set > > > the precedent that the default isn't *just* for developer debugging. > > > > > > -Michal > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > >
