Meeting 2012 02 16

Action ideas are marked: (!)

• Attendees
  • Johnny Stenback
  • pcwalton,
  • bz
  • luke
  • roc
  • benjamin smedberg (build system, COM)
  • djf (David Flanagan, initial work on DOM.JS)
  • cjones
  • dbaron
• Current work: SDL bindings, will eventually need Azure/D2D to be combined
• jst: ROC recommends getting primitive stuff DOM-etc and trying to get some measurements of the straightline performance
• jst: Want to spend some time talking about the core problems we need to ensure that we solve
  • e.g., failed at electrolysis
  • need to figure out a story for a... multi-process browser?
  • Chrome is unable to do a process per tab but...
  • Roc: thought Rust would give us lightweight threads?
  • pcwalton: Rust gives us similar to Erlang or GCD
    • not the same kind of architectural decision
    • we should be able to shift to processes at a later point
    • where it does make a difference is when you call into C++
  • host libraries
  • jst: problems with sandboxing... cross-process drawing
  • Roc: We don't know that yet, but Azure is designed for cross-process
    • My dream: try to avoid sandboxing C++ and go instead for language-level isolation via Rust
  • bz: processes per tab are needed to handle crashes in C++ Code
  • roc: if we keep too much code, we lose the point of Servo
  • jst: but we also lose the benefit of cherry-picking libraries
  • cjones: good side project might be to try and implement a JPEG decoder in Rust (!)
  • bz: Rust-tasks and memory sharing: what is the precise story?
    • multiple tasks with read-only access
  • benjamin: the whole new browser problem
    • is this really the plan? are we clear on what we are actually rewriting
    • eg, rewriting Necko?
    • bz: let's not replace what we don't have to
    • ... necko is ref-counted...?
    • roc: helps us get something going, but unless you pull in layout/dom you won't have a full browser. It's pretty easy to write some small subset of HTTP, you don't need NSS, so maybe it's better to start with simple prototypes rather than building on these unsafe libraries
    • bz: that depends on your goal. If we want to ship a full browser, we need to reuse. If we want at tech demo, maybe not. Will be faster to write a simple demo than to write the necko glue.
    • pcwalton: Rust is kind of opinionated about the network library. We prefer libuv. The reason is that libuv is non-blocking on all platforms and thus integrates well with our greenthread-based runtime.
    • bz: at some point we will need complete control over the network library. we could always fork libuv.
    • dpreston: libuv is just sockets.
    • bz: ok, fine, if we're writing our own networking library then we build on libuv.
    • jst: can we not use Necko in its own task?
  • benjamin: again, what's the goal? Go as fast as possible? Get it right and be slower? (Development speed)
    • jst: long term, probably want it all in Rust
      • short term: can we use it to bootstrap
      • writing whole network stack will take a long time
    • roc: but a new layout engine is slow too
  • benjamin: it seems like we are currently in an experimental phase in terms of dom and layout. don't want to do more work than necessary anywhere else until we are sure that dom/layout works better in Rust.
    • bz: so what is shortest path to getting there
    • benjamin: in terms of non-DOM and layout, be clear that we will not worry about it yet. Identify our success condition where we say "ok, time to start up the non-DOM/layout stuff?"
    • cjones: I agree about iterating clearly on the core. Draw module boundaries. One of the big frustrations with Gecko is the lack of those boundaries. With the right boundaries, we can implement the simple crap and scale up, either through pulling in Necko or reimpl as seems best at the time.
    • dbaron: clear boundaries don't work. example: content often needs to reach into layout.
    • jst: but there are some blocks. networking. doc navigation history. etc.
    • cjones: each block we draw gives us pipeline par.
    • bz: pipeline boundaries are more clear, had these discussions before.
      • maybe JS and layout-facing parts of DOM can be separated.
      • but have to see if that split really works.
    • dpreston: just trying to get to the point where we have network and graphics at all.
      • bz: don't need graphics at first. need something that runs a script, modifies dom, asks for layout info, prints to console, this is the key problem.
      • nmatsakis: can even mock up the layout to get lower bound
      • djf: a lot of what we want is there.
      • bz: let's try to get that hooked up. (!)
  • bz: another important goal is to figure out workloads.
    • cjones: a canvas heavy benchmark would be a good workload. touches many levels of the system.
      • pcwalton: but that's not layout
    • roc: canvas is not as hard a problem, basically async. what worries me is the sync calls to interacting with layout.
  • bz, cjones, etc: key is to test the sync calls, don't need a gfx backend.
  • benjamin: def. not talking about automatic rewriting of our codebase
    • bz: thought had crossed my mind for libpng
    • roc: libraries that are well-understood
    • luke: use JS?
    • bz, roc: we will certainly copy the algorithms, possibly reading existing code in 1 window, etc
    • pcwalton: I've always thought that translating C to Rust is a fool's errand. point is to get static/dynamic guarantees but you can get those in other ways. anyway, we can tackle this later, but if the biggest problem we have is the security of libpng, that's not a bad prob
  • cjones: a new question about writing the actual code
    • most things are done in an imperative way today
    • but one of the I liked is using a constraint-based DSL that generates optimal code and so forth
    • is that feasible?
    • roc: not convinced. there's a lot to space to go in that direction.
    • nmatsakis: probably a hybrid.
    • pcwalton: maybe there's a simpler way to cherry pick the results. something simpler like template meta-programming. basically we get code that's usually pretty good but ultimately easier to understand. basically there's often a simple kernel we can extract to make use of without getting the full complexity (or full benefits)
    • cjones: initial work that Leo did was tuning for cache hierarchy and things. I wish we had those problems.
    • pcwalton: biggest unknown is how much we can use auto-gen
  • pcwalton: contingency for shadow dom being too slow?
    • bz: we should try to figure out in the next few weeks and not worry about backup plan, if possible.
  • luke: after experimentation phase, do we plan to hollow out gecko and replace it from the inside, or do we plan to build up the experiment?
    • all: the latter
    • roc: let's not forget, we want contributors, and it's more exciting to build something new.
  • pcwalton: embedding API factors into this. webkit has shown it's a good way to get contributors.
    • pcwalton: one interesting question is the Rust embedding API.
      • brson: have to do it early to make sure that door stays open
    • dpreston: libpng is the kind of thing a Rust contributor could get into
    • bz: can you compile something like libpng into rust such that other languages can use it?
      • pcwalton: not yet. that's the bug brson opened.
    • benjamin: embedding APIs of the engine are somehow a sep. question
    • bz: can we just steal WebKit 2 API?
  • cjones: ARM port of Rust? (!)
    • cjones: Windows support? (!)
    • dherman: interns may help here.
  • bz: we should make a list of intern projects
    • bz: intern decoders are a possibility
    • jst: generating .so and .dll files
    • roc: consider possibility of an API that runs most of the code in another process
    • bz: which would automatically give us the "content process" we are interested in
    • cjones: would also help with Gecko, where we do this with plugins, using shared memory to avoid copying
  • cjones: another thing I want to bring up is extensions
    • can we all agree that Firefox extension model is broken?
      • all: Yes!
    • dherman: let's not forget this is supposed to be disruptive, we can break some of the web
    • roc: not sure how I feel about that
    • nmatsakis: depends on how broken it is
    • roc: maybe we can propose new future-proof standards
  • cjones: architectures 5 years down the road
    • major hardware targets we want to look at... GPU? etc?
    • take it offline
  • bz: who's going to do what
    • dpreston: working on SM
    • brson: bindings
    • pcwalton: shadow DOM?
  • jst: timeline for class support?
    • pcwalton: have to touch base with tjc
  • cjones: having code that actually works
  • nmatsakis: ARM support?
    • consensus: it can wait
  • luke:
    • embedding API... do we want to be the toolkit or the master?
• jst: dev-servo archives? (!)