Servo + B2G meeting on B2S

What do we need for Boot2Servo?
What parts of Gaia should we get working in Servo right away? e.g. mozbrowser iframe, make sure it's compatible with our whole iframe story
Input events - what APIs should we be using?
build system.
- servo + deps changes
- b2g integration (./build.sh servo)
gfx + events bringup (mwu + gw), glutin gonk port?
embedding story? can we go pure rust?
multi-process (with sandbox)
things needed for mini-gaia (goal: basic system app and homescreen)
- subset of mozbrowser api (aka webview)
- security model/permissions
- indexedDB
- network api (wifi)

Build system options

Can build servo inside of the B2G system or vice-versa. Probably prefer building B2G on our own in our builders to avoid adding a Servo dependency in B2G.

Rust limitations

Can't expose a C function (extern Rust function?) with variadic arguments, which is required for an Android API callback.
Other reason for C APIs were hooks to do refcounting on the C++ code. The Android HAL has an object you pass to the gfx drivers, which are refcounted, and there are fields in the objects that are pointers to the refcount-modifying methods. Need to be able to provide functions that inc/dec refcounts on objects.
Variable-sized structs that are C-compatible (e.g., for berkeley sockets). One use so far with a manually-specified field size.

Globally-stored repos instead of local to your build system.
Cargo duplicates stuff from Android build system (e.g, the repo tool)
Bizarre that we have Cargo for most things, but then git submodules for WPT tests
Why mach if you have Cargo? repo solves this (cross-compiler stuff) by pre-building and downloading binary.

Notes on how vendors work

They get a contained source tree that should be able to build in isolation

Use CEF?

Gonk needs more than EGL or GLES2 b/c of h/w compositing. Use dedicated hardware for compositing layers. NEeds special knowldege about underlying buffers (gralloc buffers can be mapped directly).
May need CEF APIs for that?
Current b2g bypasses all that and hooks in directly.
Could Gonk go "full Rust" instead of using C/C++ CEF? On B2S there's no windowing, so maybe CEF is overkill. Need CEF to boot Servo, or could just call libservo directly vs. libembedding.

Servo

Need more web APIs
Why is layers an external module? Seems like you would need tighter hooks.
Fonts required some hacks for a hardcoded list of fonts (for Android). We used an XML file.
Need to enable multiprocess. If sandboxing by default, has implications for designing message passing.

Layers

Have OpenGLES2. But h/w compositing code wants to bypass it. On B2G, the h/w composer code looks at the layers and makes the decision where to composite based on that. Saves power.

Automation

Have to build B2G to have libraries to link against
Could copy the libraries to link against - check in a built directory for Flame. B2G checkout + build is 25GB. Repos are 8gb.
Bunch of ENV variables (borrowing Android SDK for some parts, like mozjs). Should set the Gonk toolchain variables instead. mozjs configure script should do this, too (but only newer versions than the curren in Servo).

Native binding layer & xpcom JS

Can't reuse web APIs implemented in JS
Would like to rewrite it in Rust rather than trying to rehost it

mini-gaia

API surface is too huge to replicate, and some we would not replicate (e.g., Settings)
If we want to show Servo's compelling (i.e., through demos) we want to rebuild standardized APIs
MozSettings - at least talk with jonas before reimplementing
Need MozBrowser to embed iframes that work at toplevel windows, navigation events, etc.
IndexDB... blobs, etc.
Network API for WIFI, etc.

demo

Want to have the home screen panning smoothly; that alone would be compelling.