Platform/TechnologyRoadmap/Braindump
- jpr
Create a roadmap for two key reasons:
- Being deliberate about our investments and where we compete
- Ensuring technical vision matches product/user needs
We can use a roadmap to communicate internally and maintain focus and long term goals and well as present a consistent story for external partners.
Start bottom up.
See Mark Meeker's D10 Talk for reference.
- dmandelin
I'd rather have the document *not*:
- lay out overly specific goals and plans that distort developer effort
- make developers feel like they don't have input
- create unrealistic expectations or put unwelcome pressure on developers by showing unrealistic or overly specific timelines
The roadmap should support engineering teams coordination.
Another way to look at the roadmap is as a vehicle to match up interests and initiatives throughout engineering with overall strategy.
Another option for creating the roadmap: Sample concept for JS of a list of target areas and a project portfolio. I now think a vision is wanted too. The vision would be something like:
- Make SpiderMonkey the best JS engine for Firefox(| Mobile| OS)
- Help make the web the app development platform of choice
The target areas are general areas to work on over the next year or so, which right now would be something like:
- GC pauses
- developer tools support
- benchmark scores
- especially ARM
- Emscripten performance
The stuff above is all pretty general. The message is meant to include "get creative about making this stuff happen."
The project portfolio would be a list of known projects that advance those target areas. Some entries would be ongoing projects, others would be wanted projects. The portfolio isn't a schedule or a strictly prioritized list but rather works as a "jobs board"--if you're new or coming off a project, look here for something to join or start.
The main thing is that I really really really want to preserve developers' sense of autonomy, participation, and ownership as much as possible with the roadmap.
- dbaron
Think about roadmap in terms of questions that it will answer. Where is the Web going and where is it not going?
- What use cases are important for the Web to address? Already have documents, apps, device. What's next? e-book?
- In what areas do we need to be proactive to prevent vendor lock in like we see with Webkit today?
The answer to the above will drive answers to questions like:
- What layout system should we invest in after flexbox?
Maybe a roadmap is a place where we can document this common understanding.
- bz
Roadmap should answer the following type of questions for devs:
- Where are we going overall?
- How are we figuring we'll get there? What parts do we not really know yet?
- How (and whether) does what I'm doing right now fit into the overall direction?
- What are some ideas for things to work on instead or next?
- What other things are people working on that I should coordinate with?
Problems a roadmap may address:
- Working on submodules in isolation, no big picture planning.
- Having a plan for innovation.
Projects
Input from jpr, dmandelin, roc, bz
Name: Azure Drawing Layer
Description: Replace thebes drawing callings with a new API that can be hardware accelerated more easily and simplifies our drawing infrastructure
Major Component: Gfx
Motivation: Performance
Dependencies:
Timeline: In progress, complete in ~6 months
Name: IonMonkey benchmark optimizations
Description: optimize for v8 benchmarks primarily, also Kraken and SunSpider a bit
Major Component: JS
Motivation: performance marketing
Dependencies:
Timeline: 1+ months, want to shoot for V8 parity modulo GGC at least
Name: IonMonkey app optimizations
Description: optimize for web apps, demos, minor benchmarks
Major Component: JS
Motivation: performance compatibility (able to run sites that demand high perf) and marketing
Dependencies:
Timeline: 1+ months, can declare victory and move on at any time
Name: OdinMonkey
Description: run C/C++ workloads at near-native speed in browser
Major Component: JS
Motivation: games (be able to make cooler games, more reliable perf), stick NaCl in the eye
Dependencies:
Timeline: 4+ months
Name: Generational GC
Description: what it says on the tin
Major Component: JS
Motivation: responsiveness (fewer GC pauses), better benchmark scores, better app/game throughput, smaller memory footprint (via less fragmentation in JS heap)
Dependencies:
Timeline: 4+ months
Name: ES6
Description: build proposed ES6 features
Major Component: JS
Motivation: advance JS, support ES6 spec work
Dependencies:
Timeline: ongoing, ES7 will probably be here by the time we finish
Name: Perf regression monitoring that works (aka fix Talos)
Description: identify things perf things we can and want to protect against regression, make good tools for alarming on it
Major Component: tools/automation
Motivation: perf
Dependencies:
Timeline: ongoing, hopefully will get some sort of useful result sooner rather than later, although the history has been that it takes ∞ time to reach that point
Name: Fix startup outliers
Description: Fix cases where Firefox takes 2x longer than min time to start up
Major Component: cross-cutting
Motivation: biggest user dissatisfier per surveys
Dependencies:
Timeline: unknown, not started yet
Name: Shutdown exit(0)
Description: be able to exit(0) to shutdown instead of a lengthy cleanup cycle
Major Component: all
Motivation: perf
Dependencies:
Timeline: unknown, 1-2 months optimistically
Name: Fix main-thread IOs
Description: get IO off the main thread for responsiveness
Major Component: front-end, but others too
Motivation: responsiveness
Dependencies:
Timeline: ongoing, unknown ETA, trying to get more people
Name: E10S2
Description: be able to have separate processes per tab
Major Component: general
Motivation: responsiveness, crash protection, security isolation, restart processes more to improve reliability
Dependencies: partially redundant with SuperSnappy
Timeline: unknown, currently just doing background learning and experimentation
Name: SuperSnappy
Description: be able to have separate threads per tab
Major Component: general
Motivation: responsiveness
Dependencies: partially redundant with SuperSnappy
Timeline: unknown, prototype exists
Name: Fix network cache
Description: Fix locking bustage, IO problems, other responsiveness issues
Major Component: networking
Motivation: responsiveness
Dependencies:
Timeline: has been going for a while, ETA unknown
Name: Dynamic Adaptive Streaming (DASH)
Description: adaptive streaming for HTTP video to maintain constant framerate under varying network conditions
Major Component: networking
Motivation: better video experience
Dependencies:
Timeline: unknown, looks like it's a ways out
Name: Stone Ridge
Description: setup for simulating various network conditions for testing
Major Component: networking
Motivation: be able to measure networking perf so we can improve it
Dependencies:
Timeline: unknown, supposedly has a working prototype
Name: Content Display Speed Program
Description: improve the time taken until content is displayed
Major Component: networking, probably layout too
Motivation: perf
Dependencies: Stone Ridge. could probably make some progress without it
Timeline: not started yet, this is a project I am shopping around and recruiting for
Name: Easy jankometer
Description: a tool in Firefox that allows janks to be reported with almost no effort by the user
Major Component: tools
Motivation: continue responsiveness improvements once existing work is done
Dependencies:
Timeline: unknown. seems like it should be achievable in a month or two. Cleopatra is able to do this (and we are getting reports from it), it's just not absurdly easy.
Name: Layers Refactoring
Description: Share more code between our various LayerManager implementations
Major Component: Gfx
Motivation: Reduce cost of making future improvements to the layer system
Dependencies: None
Timeline: In progress, complete in ~2 months
Name: Linux GL Layers
Description: Enable accelerated layers on Linux by default
Major Component: Gfx
Motivation: Faster compositing, platform parity
Dependencies: None
Timeline: In progress, could be done any day now
Name: Layers Refactoring
Description: Share more code between our various LayerManager implementations
Major Component: Gfx
Motivation: Reduce cost of making future improvements to the layer system
Dependencies: None
Timeline: In progress, complete in ~3 months
Name: Android Hardware Video Decoding
Description: Expand our usage of Android hardware video APIs (i.e. libstagefright) to cover most users
Major Component: Media
Motivation: H.264/AAC/MP3 support on Android
Dependencies: None
Timeline: In progress. Very difficult to estimate since it depends on what the Mobile team demands, and on unknown characteristics of the Android ecosystem
Name: Windows Hardware Video Decoding
Description: Implement support for Windows Media Foundation
Major Component: Media
Motivation: H.264/AAC/MP3 support on Windows Vista/7/8+
Dependencies: None
Timeline: In progress. Complete in ~3 months
Name: WebRTC
Description: Real-time peer-to-peer audio, video and data streaming APIs for Web apps
Major Component: Media
Motivation: Free classes of Web apps (Skype, Vidyo etc) from requiring plugins or native code. Also, a good way to push use of free codecs.
Dependencies: None
Timeline: In progress. Hoping to turn on in Firefox 19, although there will be a lot of ongoing work to improve quality.
Name: Daala
Description: Next-gen free video codec
Major Component: Media
Motivation: The Web (still) needs a patent-unencumbered video format
Dependencies: None
Timeline: In progress. It's research, so very hard to predict schedule, but perhaps a year out.
Name: Web Audio
Description: Audio processing and effects API
Major Component: Media
Motivation: Web apps need an API, and this one (Google's) is winning
Dependencies: None
Timeline: In progress. Complete in ~6 months, but depends on staffing
Name: Media Source
Description: API for feeding compressed data into media pipeline via script (for adaptive streaming etc)
Major Component: Media
Motivation: Web apps need this (e.g. Netflix), other browsers will have it
Dependencies: None
Timeline: In progress. Complete in ~3 months
Name: DASH
Description: Declarative adaptive streaming API
Major Component: Media
Motivation: Web apps need this (incumbent solution is encumbered, e.g. Apple's)
Dependencies: None
Timeline: In progress. Almost done.
Name: Media Metadata
Description: API to access metadata content of media resources
Major Component: Media
Motivation: B2G apps need this (currently working around the lack of it), and probably Web apps too
Dependencies: None
Timeline: In progress. Complete in ~2 months?
Name: WebVTT
Description: Subtitle format for HTML5 video
Major Component: Media
Motivation: Web apps need it, other browsers have it
Dependencies: None
Timeline: In progress. Unclear on schedule because Dave Humphrey is doing it at Seneca (maybe only part of it)
Name: Media Element playbackRate
Description: Variable playback rate for HTML5 video
Major Component: Media
Motivation: Web apps need it, other browsers have it
Dependencies: None
Timeline: In progress. Almost done.
Name: SVG Text refactoring
Description: Share code between CSS text layout and SVG text
Major Component: Layout
Motivation: Make various CSS text layout features available to SVG and make it much easier to keep doing that for new features
Dependencies: None
Timeline: In progress. Almost done.
Name: CSS scoped stylesheets
Description: HTML feature useful for Web applications
Major Component: Layout
Motivation: Makes Web apps more modular. Smallish project.
Dependencies: None
Timeline: In progress. Complete in ~2 months?
Name: WebIDL Bindings
Description: Implement infrastructure for WebIDL bindings between Gecko and SpiderMonkey and move existing DOM classes over to the new infrastructure
Major Component: DOM
Motivation: Performance, simplifying implementation of new specifications and making our C++ code simpler/cleaner, converging with other UAs on certain corner cases, fixing various long-standing correctness bugs, making it easier to make things pref-controlled or chrome-only.
Dependencies: JIT integration
Timeline: In progress. Infrastructure is mostly in place; I expect it to be done in another several months, though there will be ongoing changes as the spec evolves. Conversion of existing classes is more open-ended, but a reasonable goal is to have most things visible in a web page converted by 6-9 months from now, at current staffing levels.
Name: Custom DNS resolver
Description: Implement a custom DNS resolver instead of relying on the OS-provided one.
Major Component: Networking
Motivation: More control over DNS resolution, ability to add new features, better ability to parallelize DNS requests.
Dependencies:
Timeline: Unclear. No one working on this yet.
Name: HTTP pipelining
Description: Turn on HTTP pipelining by default across all our products.
Major Component: Networking
Motivation: Performance
Dependencies: Unclear
Timeline: Done on mobile; not done on desktop because deemed too risky.
Name: Form control styling
Description: Design, spec, and implement sane author styling of form controls.
Major Component: Layout
Motivation: Web platform, addressing developer pain points
Dependencies: Unclear
Timeline: none yet
Name: Undo Manager
Description: Implement sane undo/redo for web editing
Major Component: Editor
Motivation: Web apps.
Dependencies: ?
Timeline: ?
