Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of purplecabbage@gmail.com
 designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <A121B9C55062F74383A10254CBA1DB6F2958A914@SINPRD3002MB008.064d.mgd.msft.net>
References: 
 <A121B9C55062F74383A10254CBA1DB6F295615CE@SINPRD3002MB008.064d.mgd.msft.net>
	<CAKP6k2uHsHBGSATZSAONCuF=AZBnWc8ykUMevQQ==CiBOxJ1uQ@mail.gmail.com>
	<A121B9C55062F74383A10254CBA1DB6F2958A914@SINPRD3002MB008.064d.mgd.msft.net>
Date: Tue, 24 Mar 2015 12:55:45 -0700
Message-ID: 
 <CAKP6k2vjVi8Fn4gTLFvfoLXgeHC8o2UXmt2RWcM2-ELfMW0Fyg@mail.gmail.com>
Subject: Re: Simulating Cordova plugins and device capabilities
From: Jesse <purplecabbage@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a1141c71615acc805120e2b04

--001a1141c71615acc805120e2b04
Content-Type: text/plain; charset=UTF-8

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.Barham@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 [purplecabbage@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.Barham@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-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

--001a1141c71615acc805120e2b04--