ripple-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Gardler (MS OPEN TECH)" <Ross.Gard...@microsoft.com>
Subject RE: Moving towards ripple 2.0
Date Fri, 21 Nov 2014 22:24:10 GMT
First off I want to be clear in my reply that (despite the signature line of this email) I
am not commenting as a Microsoft employee. I am not part of the team working on Ripple. I
was not present at the meeting discussed and I have no technical input at all. My role here
is as an ASF mentor to the project during its incubation phase. My goal is to ensure that
the community is a healthy one.

First of all I want to thank Julien for bringing this to the list as a discussion. At the
ASF we don't like project business being conducted outside of the community mailing lists.
However, in the real world people get together and talk. The correct thing to do is exactly
what is done here - have the discussions, come up with a proposal and then share the proposal
for broader community discussion.

With that in mind I want to encourage anyone reading this list to ignore the company names
involved here. Those companies might be sponsoring the time spent by those making this proposal
but it is the individuals who are responsible for engaging the community as a whole, as Julien
is doing here. Speak up and share your thoughts.

Julian - note your attachment was stripped by the mailing list software, can you put it in
a publicly accessible place (preferably in SVN if you have commit rights) and provide a link.

Thanks,
Ross

Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

From: Horn, Julian C [mailto:julian.c.horn@intel.com]
Sent: Friday, November 21, 2014 12:54 PM
To: 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message