Skip to content
brson edited this page Jan 5, 2013 · 18 revisions

So there's a lot to do. We'll try to outline the work here, with links to relevant bugs.

Some general goals for the near-term:

  • Demonstrate good performance at tasks that are hard for other engines. Servo aims to have better latency and throughput than existing engines in modern workloads. We need to identify these scenarios, create test cases, and orient our work towards implementing them. Latency is particularly important for user experience demos; throughput is good for benchmarks.
  • Implement the entire Servo architecture, including a multi-process front end. Although true sandboxing is not a near term goal, we want to design Servo's interface for sandboxing, and being multi-process from the start will make that easier.

We have discussed milestones in the past. We may want to revisit ideas for milestones and dates, e.g. display Wikipedia, pass Acid1.

Near-term

Architecture, infrastructure, cleanup

DOM and display list type safety; refactoring; test suite; bots; navigation

Unified in-memory caches

There are many caches all up and down the browser stack, for things like images, fonts, glyphs, text runs, and numerous unimagined future things. Additionally servo often has dual caches for any particular thing, one remote cache in a dedicated task and another task-local cache. As control over memory usage is critical in web browsers we should plan on making this robust from the outset.

https://github.com/mozilla/servo/issues/238

Local storage

Servo doesn't have any local storage. This will be needed for history, bookmarks, caching and a million other things. At this time we are inclined to use LevelDB for everything, so a good place to start would be LevelDB bindings. Then move on to some of the common browser features and figure out how to integrate them into the engine.

https://github.com/mozilla/servo/issues/244

Content

navigation

interface design, content deals with a lot of messages to and from different sources. needs a clear strategy. how are DOM events sourced and routed? likewise input events? various parser message flows.

Parsing
  • make sure all parsing is asynchronous. we should never (or rarely) be blocking on parsing
  • parse inline JavaScript and CSS
JavaScript
  • Get basic JavaScript support up and running, enough to implement simple animations and the like. Get onclick working. Maybe navigation too.
DOM bindings
  • We need the beginnings of a non-toy, production DOM.

  • This may depend on some Rust work to implement safe single inheritance. We can use unsafe code in the meantime.

  • We need to decide how much copy on write (COW) we want to do. pcwalton and brson are beginning to think that COW should be shelved over complexity and performance issues.

  • Gecko uses a very advanced system for generating DOM bindings from WebIDL (the Paris bindings), developed through years of experience. It is apparently very good, so we should adopt it for servo as well. https://github.com/mozilla/servo/issues/240

Layout

  • We need floats to pass Acid1 and to render most Web content.

Graphics

Image decoding

Our current image-decoding library, stb-image, is slow, not suitable for a web browser. We need our own image decoding library, initially based off existing high-performance decoders, and expandable to Rust-based decoders later.

https://github.com/mozilla/servo/issues/237

Networking

Implement HTTP and the bindings and networking features it requires

We have very primitive HTTP support, built upon the Rust standard library and the Joyent HTTP parser. Needs a lot of work. It can be a rewrite as the existing design is poor. It's probably best to start by binding NSS since it will impose some implementation restrictions.

https://github.com/mozilla/servo/issues/239

Sandbox

Frontend

Web API's

Performance measurement

Testing

Instrumentation

We need to be able to make repeatable performance measurements of various kinds. There is very minimal code for this already in servo in the form of a time function, but we need much more. We want servo designed for gecko-style telemetry from the beginning, so it would serve us well to do some up-front investigation into what they are doing.

https://github.com/mozilla/servo/issues/241

Long-term

HTML

CSS

Rewrite rust-css

rust-css is our CSS parser and selector matching library. It is currently a thin wrapper around NetSurf's libcss library. Ideally we can rewrite this in two phases - first the parser, then the selector matcher, but they may be too intertwined for that to be a viable strategy.

https://github.com/mozilla/servo/issues/243

Web API's

Codecs

Networking

Sandbox