Re: Moving towards ripple 2.0

[Brent Lintner <br...@gmail.com>]

Hey Julian (and all),

I do apologize for my uber late reply here (although, via lazy consensus I
didn't see any opinionated "red flags" with the proposed direction).

After reading things more in depth, FWIW: I am a fan of separating the
simulator UI away from the app host in general, as you could easily use
browser tools like Web Inspector (which has great mobile tooling now) to do
a lot of the mobile device layout simulation that Ripple attempts to do,
while just using Ripple's UI (in a separate tab) for modifying extra things
(GPS, etc).

Only one thing on my mind would be (sticking to a long ago ideal), that you
could run this in any browser still, and if that is truly something that
people care about. It could be that Cordova is indeed the primary use case
for a tool like this, though (and as such, it is prudent to build on top of
Cordova Browser). And, for the mobile web (in general), users could get the
same value by using vanilla browser tooling like Web Inspector.

Hopefully that makes sense. ;-)

All the best, and hope the work is going well (if it has started or is
planned to be), if so. Here to help if I can (when I can). :-)

On Mon, 24 Nov 2014 at 20:00 Ross Gardler (MS OPEN TECH) <
Ross.Gardler@microsoft.com> wrote:

> Thanks for this Ali.
>
> Given that the Ripple community is not a vibrant one at this point your
> engagement like this is good. We need to ensure that any lurkers feel
> included (which you are doing well) whilst also ensuring that you can
> proceed as planned (assuming no objections from the community that is
> active).
>
> In order to ensure your proposal is considered fully and you are able to
> proceed, it might be worth you reading about the concept of Lazy Consensus
> in ASF projects - very valuable in situations like this and it should
> describe how to move forwards with your proposal -
> http://community.apache.org/committers/lazyConsensus.html
>
> Ross
>
> Microsoft Open Technologies, Inc.
> A subsidiary of Microsoft Corporation
>
> -----Original Message-----
> From: Ali Satter [mailto:Ali.Satter@microsoft.com]
> Sent: Monday, November 24, 2014 4:28 PM
> To: dev@ripple.incubator.apache.org
> Cc: julian.c.horn@intel.com; Ryan J. Salva
> Subject: RE: Moving towards ripple 2.0
>
> Thank you Julian for the summary.  The gist of the proposal is take the
> core of Ripple and split it up to support the various scenarios the
> community has been discussing.  Please take a look at the high level
> proposal and share your thoughts.
>
> PPT http://1drv.ms/1xP6bbI
> PDF http://1drv.ms/11ruAY9
>
>
> -
> ali
>
>
> From: Horn, Julian C [mailto:julian.c.horn@intel.com]
> Sent: Friday, November 21, 2014 2:28 PM
> To: dev@ripple.incubator.apache.org<mailto:dev@ripple.incubator.apache.org
> >
> Subject: RE: Moving towards ripple 2.0
>
> I see the mail daemon stripped out my attachment.  I tried pasting the
> foils into the mail, but it was too big.  Here are the foils in outline
> mode.
>
> Cordova-browser compared to Ripple
> *       Julian Horn
> *       November 19, 2014
>
> Overview
> *       Both "ripple as a platform" and the "cordova browser" platform
> leverage the Cordova CLI to prepare sources for execution on host
> -      Cordova prepare browser => run in browser
> -      Cordova prepare ripple => run in Ripple (in browser)
> *       Device layout emulation either comes from the browser's dev tools
> "emulation" feature or from Ripple
> *       In both cases, the program under test runs in the host system's
> web runtime, so faithfulness to on-device experience is limited
>
> Deeper Differences
> *       Cordova-browser is a deployment platform, like other cordova
> platforms
> *       Ripple is a diagnostic platform whose goal is to approximate the
> feeling of running on device as a packaged app
> -      (With the big caveat that you're running in the host system web
> runtime)
> *       Ripple supplies extensible GUI framework that allows plugin
> emulation logic to interact with user
> -      Browser dev tools UI is not extensible in this way
>
> Example: Cordova Camera API
> *       Browser platform implementation uses a non-standard API,
> getUserMedia, to access the camera
> -      If browser doesn't support getUserMedia or host has no camera =>
> error
> *       Logic: reproduce feeling of running in host system browser (or
> failing if it can't run)
> *       Ripple platform implementation tries to bridge the gap between
> host (think desktop PC) and target (think phone)
> *       Logic: exercise camera-based app on host, even if that app is not
> intended to run on a desktop environment
>
> Levels of Support
> *       Emulation of camera API can work at several levels:
> -      Always return "canned" data from fixed files (no user interaction)
> -      Use host system camera if present, else fixed files (no user
> interaction)
> -      Let user decide what should happen (user interaction)
> *       Best choice probably depends on what the app does
>
> Ripple platform can Reuse Browser platform
> *       Ripple implementation can delegate to browser implementation when
> requested ("use host system camera") or when ripple has no implementation
> of its own
> -      Some Ripple API emulations already delegate to a host system API
> -      Example: emulation for Cordova File API delegates to Filesystem API
> -      Note that this can be problematic:
>
> Last foil had this image:
> [cid:image001.png@01D005B0.75C2FB80]
>
> From: Horn, Julian C [mailto:julian.c.horn@intel.com]
> Sent: Friday, November 21, 2014 3:54 PM
> To: dev@ripple.incubator.apache.org<mailto:dev@ripple.incubator.apache.org
> >
> Subject: Moving towards ripple 2.0
>
> As people may know, we at Intel have been hosting a series of meetings to
> discuss the future of Ripple, and to explore various ways to collaborate on
> Ripple development.  As ideas become a little clearer we share the progress
> on this mailing list.  People may remember, for example, my posts on the
> subject "Summarizing thoughts on cordova-browser vs Ripple", and "Ripple
> prototype that pulls in emulation code from plugins" which derive from
> these discussions.
>
> We had another meeting on Wednesday, November 19, and I would like to
> share what was discussed for people who are curious or could not attend.
> As it happened, we conflicted with the Chrome dev summit.
>
> I have attached a PDF form of some foils I presented to frame the
> discussion about cordova-browser versus Ripple.  To summarize briefly, our
> position is that Ripple is not redundant with cordova-browser.  The foils
> describe a concrete example illustrating that difference in emphasis and
> the points of overlap.  We definitely see value going forwards with
> Ripple-like emulation. I am happy to say that there was agreement on this
> point among the people who attended.
>
> The meeting then moved to a discussion of how Ripple might evolve going
> forwards.  I'm not really the best person to summarize this part of the
> discussion, as most of these ideas were described in foils presented by our
> friends from Microsoft.  I expect them to share their foils with this list
> soon.  They intend to flesh things out to provide more context and
> hopefully a walk-through example.  We can then have more public discussion
> to get everyone's feedback.
>
> That being said, I will give you a quick teaser.
>
> The vision here is that the Ripple client would be split into two
> processes. One process, called the "simulation process" contains the
> program under test and various kinds of emulation infrastructure, but no
> emulator UI.  This more or less corresponds to the inner frame in Ripple.
> The other process, called the "simulation host" contains the emulator UI.
> This could either run stand-alone as the Ripple client does or be embedded
> in an IDE. Emulator UI widgets (think Ripple "panel") and supporting code
> can be extracted from included plugins and incorporated into a simulation
> host, in a manner similar to the Ripple prototype I described in earlier
> mail.
>
> Ripple 2.0 thus becomes the reference implementation of a simulation host,
> but anyone is free to develop their own simulation host.  Code in plugins,
> both emulation code and cordova-browser code, is shared across simulation
> hosts.  This should be a big improvement over the current situation, where
> there has been little sharing among the various Ripple derivatives that
> exist.
>
> I should stop here and let the authors present the details of their plan
> before commenting further.
>
>     Julian
>