Thanks Michal and Jesse! Jesse, in response to your additional questions...
> What value does Ripple if the basic functionality becomes part of a > generic simulation interface? > > Ripple currently will simulate screen sizes based on device choice. > Chrome dev tools support picking different device viewports also. > Where should something like this live? Julian Horn (Intel) would be a good person to answer that question... He can speak more eloquently than me to why Ripple is (and will continue to be, after this proposal is implemented) the ideal platform for them. And I think there is definitely room for both approaches: * Some basic simulation host provided by Cordova, which wouldn't provide any of the "device choosing" capabilities and other functionality we get with Ripple, but would work well with browser dev tools (and rely on them to provide that functionality). * A richer environment like Ripple, which is also works well embedded in tools like the XDK. Another interesting point is that Chrome device mode means you have the Chrome debugger open, which means you can't use an external debugger. If your workflow is entirely Chrome, then that works very well. If we're talking about using Chrome with external debuggers (like Intel XDK or Visual Studio), then device mode becomes problematic and something like Ripple works well. > Is this feature valuable enough to warrant this lengthy discussion? It's certainly valuable to certain groups :). But for me I think it's more a case that it will involve a significant amount of effort and I want to get sign off from the community now rather than spending a bunch of time going down a path that might get rejected down the line. Thanks again! Tim -----Original Message----- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Wednesday, March 25, 2015 8:32 AM To: dev Subject: Re: Simulating Cordova plugins and device capabilities This is exceptionally cool (and thanks for doing a video demonstration, great way to get the point across)! I also agree with all your points, and really support this approach. Specifically: +1 browser platform will be used for both prod and debugging, so cannot have always-on emulation. +1 to have emulation hooks inside cordova browser platform and cordova plugins' browser versions, but have them no-op by default. +1 to support any downstream emulation embedders, and perhaps have a +very lightweight cordova project (though perhaps not necessary beyond a simple testing app). +1 to suggest Ripple become an embedder. I'll also note that Microsoft is one of the primary supporters of Ripple recently, so if they think this is a good direction, that is a strong signal to me. Intel is a second strong supporter or ripple (anyone else?), and I think they were on board with this direction as well (to build on top of browser platform). -Michal On Tue, Mar 24, 2015 at 3:55 PM, Jesse <purplecabb...@gmail.com> wrote: > Thank you Tim for the brief explanation! ;) > > I agree with all your summary points. > > Some more questions: > > What value does Ripple if the basic functionality becomes part of a > generic simulation interface? > > Ripple currently will simulate screen sizes based on device choice. > Chrome dev tools support picking different device viewports also. > Where should something like this live? > > Is this feature valuable enough to warrant this lengthy discussion? > I have no idea how useful this will actually be. As someone who has > released apps for most of our supported platforms I have never needed > ripple of any other simulation, short of stubbing cordova-exec and > working out all my UI/UX in a browser. Is there some way we can measure the > need? > Given that this does not appear to impact cordova, just supplement it, > you should probably just go for it. Fixing cordova-serve and getting > cordova-browser to use it are already in discussions, so moving > forward with another module 'cordova-platform-sim'? sounds good to me. > > Cheers, > Jesse > > > > @purplecabbage > risingj.com > > On Mon, Mar 23, 2015 at 7:08 AM, Tim Barham <tim.bar...@microsoft.com> > wrote: > > > Hey Jesse - thanks for the feedback! > > > > First I'd like to address why we think this belongs in Cordova > > rather > than > > Ripple: > > > > *. The functionality described is closely tied to how Cordova works, > > and we feel is a capability that should be built into Cordova - > > specifically, that Cordova provide the hooks necessary for any > > arbitrary "simulation host" to connect to. > > *. We don't see this as being a Ripple replacement, per se. Rather, > > is this model, Ripple would become one of any number of "simulation hosts" > > built on top of this. > > > > Cordova might include a very basic "simulation host" out of the box, > while > > Ripple would remain a much richer, but separate, project built on > > top of the same functionality. > > > > Why do we see the need for this when we already have Ripple? Reasons > > include: > > > > * We want to make it easy to embed a "simulation host" in other > > environments. Ripple is just one example.. Also within an IDE, or > > within > a > > browser's dev tools, or whatever. > > * As mentioned below, we want to separate the simulation UI from the > > app itself to simplify the debugging experience. > > * We want to make it easily extensible - specifically allow plugins > > to define their simulation UI and have it work in any simulation host. > > > > Regarding the "browser vs Ripple" thread - yeah, I remember it :). > > We > were > > following it at the time, and it definitely influenced what we are > > proposing. Some points on this: > > > > * We don't think it should be "browser vs Ripple"... We think it > > should > be > > "Ripple on top of browser" :) ... but most importantly we don't > > limit > this > > to Ripple. May simulation hosts proliferate! > > * If I recall there was also discussion about whether the browser > platform > > is primarily a debugging tool or a real production delivery > > platform. Our firm belief is that it is both. We can easily provide > > the hooks (the 'app host' and 'server' pieces) so a rich debugging > > environment like Ripple > can > > be built on top of it (and, of course, also open the door to other > > simulation hosts) without taking anything away from it being a real > > delivery platform. > > > > So, in summary, this is how I'm thinking about it: > > > > * The browser platform continues to be a production delivery > > platform. It doesn't provide any UI for simulating plugins. Plugins > > should always just do the "real thing", and never provide mock data or > > anything like that. > > * The browser platform, when run from the Cordova CLI, is modified > > to launch from a server. Something we'd want to do regardless. > > * That server provides the hooks a simulation host needs to do its > > thing (but, most likely, those hooks would only be available if the > > application was launched in a mode to expect plugin simulation). > > * The simulation host itself is completely separate from the browser > > platform. Completely separate from Cordova, in fact, though > > personally > I'd > > also love to see a basic simulation host available as part of > > Cordova > (but > > in its own module). > > > > Tim > > > > ________________________________________ > > From: Jesse [purplecabb...@gmail.com] > > Sent: Thursday, March 19, 2015 2:44 AM > > To: dev@cordova.apache.org > > Subject: Re: Simulating Cordova plugins and device capabilities > > > > Hi Tim, > > > > Nice work. I was going to point you towards Ripple[1], until I saw > > you > have > > the most recent commit. Can you elaborate on why/how you feel this > > fits into cordova and not into the ripple project? > > > > Personally, I think it is a better fit in ripple, or at the minimum, > > as a separate module/repo in cordova that can function and be added > > independently. > > > > There is a lengthy discussion on browser vs ripple here [2] > > > > [1] https://github.com/apache/incubator-ripple > > [2] http://callback.markmail.org/thread/mxwnjp4lnz7kfzrr > > > > > > > > @purplecabbage > > risingj.com > > > > On Wed, Mar 18, 2015 at 2:04 AM, Tim Barham > > <tim.bar...@microsoft.com> > > wrote: > > > > > Hey everyone... I would like to introduce a proposal and > proof-of-concept > > > prototype that we have been working on. The proposal is to provide > > > a tool/feature that allows you to simulate Cordova plugins and > > > device capabilities when a Cordova app is launched in your desktop > > > browser. > > > > > > The goals for this proposal were: > > > > > > 1. Keep the simulation UI out of the app's window. > > > 2. Provide an extensible model for simulating plugins and device > > > capabilities. > > > > > > I've created some resources to introduce the proposal: > > > > > > * Document describing the proposal and the proof-of-concept prototype: > > > http://goo.gl/XJ25vL > > > * Short video demonstrating the prototype: http://goo.gl/Nf8UBp > > > * Document describing how to install the prototype to try it for > > yourself: > > > http://goo.gl/MyiNas > > > > > > I'd like to emphasize that the prototype was developed purely as a > > > proof-of-concept, and is not intended to suggest the final > > implementation. > > > > > > We'd greatly appreciate it if members of the Cordova community > > > could > take > > > a look and provide feedback - any and all feedback is welcome! But > > > as a starting point: > > > > > > * What do you think of the idea in general? > > > * Where should it live? In cordova-browser (like the prototype)? A > > > separate Cordova module? Entirely external to Cordova? > > > * What are the must-have features for an initial release? How > > > would we like to see it evolve in the future? > > > * Any thoughts on implementation details? > > > > > > Thanks, and looking forward to your input! > > > > > > Tim > > > > > > > > > ------------------------------------------------------------------ > > > --- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > >
