Hi Ross,
Thanks for the coaching. You're absolutely right, I don't want this to sound
like an official announcement from Microsoft or Intel; this was a meeting of
individuals and I should have made that distinction clear.
Julian
-----Original Message-----
From: Ross Gardler (MS OPEN TECH) [mailto:[email protected]]
Sent: Friday, November 21, 2014 5:24 PM
To: [email protected]
Subject: RE: Moving towards ripple 2.0
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:[email protected]]
Sent: Friday, November 21, 2014 12:54 PM
To: [email protected]
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
