Roadmap

Written on January 1st , 2021 by Anselm Hook

OVERVIEW

This is a high level road map document for Orbital. The goal of this document is to answer questions like: “What are we doing next?”, “What’s the actual plan?”, “Why are we doing this now?”.

Our first technical goal is to provide a capability for dynamically loadable durable persistent apps. In some ways this can be thought of as similar to an app store, or a desktop operating system, in that apps are durable and persistent on the client, and sandboxed in a way that they cannot interfere with each other or with other user files and assets.

It’s almost a given that typical media experiences on the web will shift away from look-at style text interfaces that block the world to look-through style blended interfaces that add digital buttons or verbs to the real world. Even for people without eyesight or hearing, there may be a ‘situated in place’ or ‘embodied’ representation of actions they can take. To support this we also want to explore having the browser act as a user agent to filter between competing inputs and reduce noise.

Finally, we’re also especially interested in portability and ease of compilation for new hardware. It also seems likely that new hardware will emerge rapidly. It should be straightforward for hardware vendors to compile this browser and have access to the entire browser ecosystem quickly.

1. Prototyping support for persistent apps

In general we are standing on the shoulders of giants, leveraging Servo, Rust and other tools. Rust itself already provides a crates like concept which is a good starting point. But we will want to carefully sandbox anything that we’re fetching from remote and allowing to run locally. We’ll also want a user visible app-store like interface for viewing what apps are downloaded.

This work is situated between a web browser - which typically provides only weak concepts of persistence (especially as PWA is being deprecated) and a full operating system. It could be thought of as a lightweight operating system inside of an operating system.

Approach:

  1. Attach/formalize a sandboxed crates environment to Servo that can run apps on demand
  2. Expose an API that allows userland scripts to talk to this sandbox
  3. Write a userland web app to allow viewing the sandboxed crate environment (an app store)
  4. Target only a single piece of hardware for first version (MacOSX)

Validation:

  1. We should be able to visit a website and have it ask to persist an app locally
  2. The website should be able to save and update apps and also fulfill crate dependencies
  3. It should be able to browse only portions of the file-system it has access to
  4. The sandboxing in general may need to demonstrate throttling CPU on any processes/threads
  5. Users should be able to browse what apps are locally stored (and add/remove/start/stop)
  6. A persistent app should be able to avoid being refetched if it is up to date
  7. A persistent app should be able to talk to the display and produce routine user interactions

Challenges:

  1. We have to sandbox filesystem access, having crates write to our filesystem wrapper
  2. We will want to pass threads through to real thread-runner probably
  3. We will want to look at sandboxing capabilities of rust threads. See https://github.com/unrelentingtech/rusty-sandbox . Also see https://github.com/servo/gaol .
  4. We need to understand how far towards full blown OS features we need to go. Can we just wrap existing capabilities? There is interesting standalone work here that may also be useful as a reference: https://github.com/tomaka/redshirt .

2. Flexing Capabilities and new Hardware support

Our goals here are to start to test capabilities. Notably, can HTML itself be turned into “just another app” rather than being treated as a privileged or built in capability? As well we want to demonstrate an ability to run on more than one hardware platform.

Approach:

  1. Move Servo layout engine itself out of the kernel and treat it as “just another app”.
  2. Build a simple multiplayer VR world demo as an example “rich app”.
  3. Test build on new hardware.

Challenges:

  1. Test allowing multiple apps to write to the same view and scene graph as a stretch goal.
  2. Which new hardware is best? Ideally would prefer AR glasses or something truly new.
  3. Android may be a good target however.

3. Feature Matrix and automated builds

The goal here is to formalize a build environment so that other developers can contribute. We will also want to port to a third platform because ease of supporting new hardware is critical. Finally we want to write up and document this effort overall to share with the community.

Approach:

  1. Using Jenkins we’ll automate build with unit tests across all platforms
  2. All pass/fails will be reported to a feature matrix visible on the website
  3. Pick a third platform and port
  4. Write up each piece of this research and publish on web; encourage feedback and participation.
Share!

You may also enjoy...