Simulator v4 proposal

[Myk Melez]

Toolsmiths!

Given the engineers to do the work, the most important big goals for the
next release of the Simulator would be:

* optimize the devtools experience: make it dead simple to start an
app with remote tools connected
* minimize the size: shrink the addon by reusing Firefox's XULRunner
* complete the simulation: mock the APIs that are not yet supported
<https://developer.mozilla.org/en-US/docs/Tools/Firefox_OS_Simulator#Unsupported_APIs>
(modulo hardware-dependent APIs)


And other important goals that I would defer to the version after that
(making them non-goals for the next version) include:

* support multiple branches: of B2G/Gaia, so developers can test apps
against the various versions headed to market
* replace the ADB client: with a jsctypes reimplementation, to improve
its reliability and reduce the size of the addon further


But we don't yet have the engineers to tackle these large projects
within a reasonable timeframe, and I'm loathe to stretch the development
cycle too far. So I triaged issues to identify a set of bug fixes and
(mostly minor) enhancements that notably improve the experience and are
possible to address within a month or so with our existing capacity:

https://github.com/mozilla/r2d2b2g/issues?direction=asc&milestone=4&sort=created&state=open


I propose we tackle these issues over the next four weeks, from today,
Tuesday, May 14 to Tuesday, June 11; then ship the next version two
weeks after that, on Tuesday, June 25.

This wouldn't mean that we'd reject other work, of course. As always,
additional contributions are welcome and encouraged. And other issues
will undoubtedly arise that cause us to adjust priorities. It just means
that this would be the initial set of issues that I and the engineer
currently dedicated to the project would prioritize and focus on.

Thoughts?

-myk

[Dave Townsend]

On Tue, May 14, 2013 at 11:54 AM, Myk Melez <m...@mozilla.org> wrote:

> * minimize the size: shrink the addon by reusing Firefox's XULRunner
>

I think this is a really hard piece, I don't see it in the triaged set of
issues for the next release (rightly so!) but I think we need to start
working on it now, at the very least by identifying what differs between
gaia-desktop and stock firefox xulrunner that impacts simulator. Remember
any changes we make to Firefox will take up to 18 weeks to ship before
simulator can rely on them

[Jeff Griffiths]

That's a great tactical suggestion and I would consider it a high
priority to identify what platform changes we need. I guess we first
need some analysis of where the gaps are. Who is best places to drive
this analysis?

Jeff

[Alexandre poirot]

+1 on the important items selection!
+1 on the need of resources!

I think we can gain from gaia team collaboration to mock APIs in the helper
addon shipped in Gaia.

https://github.com/mozilla-b2g/gaia/tree/master/tools/extensions/desktop-helper
Vivien recently landed something to mock TouchEvents and some other gaia
contributors already fixed some edges cases.

About the first item and devtools integration, I think that we can simplify
this step a lot by running tools in the simulation process so that we
wouldn't have to wait for remote tools to work. It could also simplify the
UX by having only one window!
Now that we have a Refresh command, you would get back to Firefox window to
see the apps dashboard only when you want to register a new app.

2013/5/14 Jeff Griffiths <jgrif...@mozilla.com>

FYI, I've already started working on that and a big part of this work has
already been done by gaia team, especially Vivien and Kevin, who worked on
"desktop helper addon" and various patches against mozilla-central in order
to make Gaia work again on Firefox desktop! (Mostly replace some hardcoded
#ifdef by runtime preferences)
The good news is that most of the non-hardware related API are already
known to work on Firefox 23.
We can easily identify what works or not by running gaia on Firefox with:
$ cd gaia/
$ BROWSER=1 make
$ /path/to/firefox -profile profile
I encourage anyone to give it a try, *all* devtools already work in this
mode!

In parallel, I've already started trying to launch firefox instead of b2g
desktop and that lead me to enable gaia helper addon in simulator
https://github.com/mozilla/r2d2b2g/pull/510 and also simplify some aspects
of the simulator to ease this switch
https://github.com/mozilla/r2d2b2g/pull/488. I don't have a precise set of
bugs/modification to run on top of firefox as I'm trying to land small
changes step by step, but I dedicate a big part of my time on this.

Otherwise, there is something very important in reusing firefox runtime: we
are no longer going to run on gecko 18.
For me, that's a very good thing. Uplifting to v1-train introduce risk for
the product, but v1-train also lacks of devtools efforts. So that if we
want to really improve the simulator by tuning code from mozilla-central,
we would have to always request uplifting and I'm not sure that's the best
thing to do.
I rather prefer having efficient and feature-full developer tools than
something that act more like a v1 version.
Then, my hope is that devices will be updated and quickly reach the "X"
version that is going to ship our current and coming devtools improvements
in Gecko/Gaia.

[Panos Astithas]

On Tue, May 14, 2013 at 11:47 PM, Alexandre poirot <poiro...@gmail.com>wrote:

> Otherwise, there is something very important in reusing firefox runtime: we
> are no longer going to run on gecko 18.
> For me, that's a very good thing. Uplifting to v1-train introduce risk for
> the product, but v1-train also lacks of devtools efforts. So that if we
> want to really improve the simulator by tuning code from mozilla-central,
> we would have to always request uplifting and I'm not sure that's the best
> thing to do.
> I rather prefer having efficient and feature-full developer tools than
> something that act more like a v1 version.
> Then, my hope is that devices will be updated and quickly reach the "X"
> version that is going to ship our current and coming devtools improvements
> in Gecko/Gaia.
>

The problem with this approach is that developers that start writing their
apps against the simulator may come to depend on features that are not
present on the device and then being frustrated about having to debug on
the device as well. This may be expected for missing or simulated hardware
APIs, but consider things like ES6 features, or no longer vendor-prefixed
properties, or new CSS or DOM APIs that will not be available in gecko-18,
gecko-23 or whatever version future Firefox OS releases will be based on.
Fidelity of the simulation is a core feature of a simulator IMHO.

Uplifting our changes to v1-train (or vX-train in the future) is indeed a
problem, but I think the current solution of a simulator-specific b2g build
is the best compromise. This way we can make our own judgment calls on the
risk of various changes without impacting the product that ships on
devices, which would require releng and partner buy-in.

Panos

[Alexandre poirot]

2013/5/15 Panos Astithas <pa...@mozilla.com>

For me, running on a precise environnment version is this other goal:

> * support multiple branches: of B2G/Gaia, so developers can test apps
> against the various versions headed to market

Still an important goal, but I'd make it after having a better tool for
people that do not care about version specific issues.

Otherwise, what you are saying here is what I typically want to highlight.
The main benefit of running on top of Firefox is to strip down the xpi. And
if we do this, we will loose what you described here and I know various
people really care about this.
So I'm clearly asking if we really want to do that...

[Myk Melez]

On 2013/05/14 13:47, Alexandre poirot wrote:
> +1 on the important items selection!
> +1 on the need of resources!
>
> I think we can gain from gaia team collaboration to mock APIs in the
> helper addon shipped in Gaia.
> https://github.com/mozilla-b2g/gaia/tree/master/tools/extensions/desktop-helper
> Vivien recently landed something to mock TouchEvents and some other
> gaia contributors already fixed some edges cases.

Yes, we should be able to benefit from some of this work, and that's a
good thing. But it doesn't mean we can aim to finish the work within a
reasonable timeframe. It still seems out of reach for a June release.

> About the first item and devtools integration, I think that we can
> simplify this step a lot by running tools in the simulation process so
> that we wouldn't have to wait for remote tools to work. It could also
> simplify the UX by having only one window!
> Now that we have a Refresh command, you would get back to Firefox
> window to see the apps dashboard only when you want to register a new app.

This idea has potential, and I think it's worth pursuing for the UX
benefits alone. But again I don't think it'd save us enough time to make
the work feasible for the next release, since the tool interfaces seem
to have dependencies on the Firefox browser window, and integrating them
into the Simulator's window will take a significant amount of work.

-myk

[Myk Melez]

On 2013/05/15 01:08, Alexandre poirot wrote:
> 2013/5/15 Panos Astithas <pa...@mozilla.com <mailto:pa...@mozilla.com>>

We want to do both things, and figuring out which to do first is a
question of priorities.

I've been prioritizing reusing Firefox's XULRunner over supporting
multiple branches of B2G/Gaia because Simulator footprint is a known
issue for developers at download/install time (and to a lesser extent
also Firefox startup time, although there are other ways to mitigate
that impact). Thus my proposal that "reuse Firefox's XULRunner" be a v.N
feature while "support multiple branches of B2G/Gaia" be v.N+1 (for some
value of N).

canuckistani and bmaggs (cc:ed) might argue that those priorities should
be switched and that the latter is more important, per their user story
" as a developer I want to be able to simulate more than one B2G target
running my app, more or less at the same time." But footprint and
performance, like reliability and security, are core "features" of all
good products, so we cannot discount them merely because they lack a
user story; we must rather choose to trade them off wisely.

Notwithstanding all that, I still don't think we can do either for the
v.Next release (the particular value of N in question), given the number
of engineers currently dedicated to the project. So I continue to
propose that we instead fix/implement this small set of bugs and mostly
minor enhancements for it:

https://github.com/mozilla/r2d2b2g/issues?direction=asc&milestone=4&sort=created&state=open

-myk

[Myk Melez]

On 2013/05/14 11:54, Myk Melez wrote:
>
> https://github.com/mozilla/r2d2b2g/issues?direction=asc&milestone=4&sort=created&state=open
>
>
> I propose we tackle these issues over the next four weeks, from today,
> Tuesday, May 14 to Tuesday, June 11; then ship the next version two
> weeks after that, on Tuesday, June 25.
>

Ok, I didn't hear any significant objections, so this is what we'll do,
and it is now the plan of record!

-myk