Thanks, Julian. Great summary! Best, Serge @lunarserge
-----Original Message----- From: Horn, Julian C [mailto:julian.c.h...@intel.com] Sent: Tuesday, November 18, 2014 1:58 PM To: dev@cordova.apache.org Subject: RE: Summarizing thoughts on cordova-browser vs Ripple I'd like to answer some of the concerns that have flown by in this thread. Let me work from most recent to older. First, in reply to Jesse's question, yes, this is how Ripple works today: it can run code prepared for any platform. That is, when you start to emulate a Cordova 3 project, Ripple calculates the platform associated with the currently selected device. So if the current device is an iPhone 5, the platform is "ios". Ripple then shells out to run a "cordova prepare ios". When that finishes, Ripple starts executing the output, which would be in platform/ios/www. This means you are executing the ios-specific sources for your app under ios emulation. If you have any merges, they would be resolved according to the ios rules. The point of the cordova-browser and ripple-as-a-platform idea is to stop doing this, and rather have Ripple shell out to do "cordova prepare browser" (or "cordova prepare ripple") no matter what device is selected. This means you are executing not os-specific sources, but rather generic sources that are intended on a browser (or in a browser in ripple). The distinction between these two cases is what started this mail thread. I think Serge what is saying that he likes the possibility of being able to package the emulation support for a plugin API in with the plugin itself, rather than having all the emulation support be in the emulator, as has been the case in the past. This provides a nice extensibility point that plugin authors could use as they see fit. As for Brian's question about UI support in plugins, it's certainly true that anyone who wants to design a UI model for emulation of some new API will have to work within some extensible GUI context. This is really what Ripple gives you. The browser does not, and it seems unlikely that the developer tools in multiple browsers could agree on some kind of common extensibility framework. For example, the Ripple UI provides the concept of a "panel". This is a separable module that is defined by its own HTML and CSS, along with whatever images or third party components are needed to make it all work. It's easy to add a panel to Ripple, and with that you get for free a framework where that panel can be opened, closed, hidden, and arranged within an accordion with other panels and so on. I made a prototype version of Ripple that demonstrates that it is possible to embed a panel definition into a plugin and have Ripple discover that panel and dynamically add it to the rest of the Ripple UI, as if it were part of Ripple to begin with. So this is certainly doable. It's the same amount of work to author and maintain the emulation code, no matter how it is packaged. As to whether Ripple is "dead" or not, I would like to point out that Intel has a Ripple-derived product (we call it the Device Emulator) that is alive and well. It does not run as a stand-alone tool, but rather is integrated into the Intel XDK IDE. It is under active development and support. It has diverged somewhat from Ripple, mainly in the way it is integrated into the XDK and the way it supports Cordova 3. For example, we have an "auto-refresh" option that causes the emulator to restart when you modify a source file. We also have a button that launches a variant of the developer tools that appears to debug only the program under test, even though this is just one frame in a larger document. Julian -----Original Message----- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Tuesday, November 18, 2014 4:04 PM To: dev@cordova.apache.org Subject: Re: Summarizing thoughts on cordova-browser vs Ripple 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 > > > B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[ ] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ ] Z[ ܙݘK \X K ܙ B --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
