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 > > > > >
