# Use-cases

* Mirage cache
* Editor Domain
* COTF2
* Target Domain / Build Store

# General

* Switch to CMake projects for cross-platform builds?
* Should get rid of stack-dependent RefCount initialization
* Upgrade to CPR 1.6.0 for more efficient downloads
* Implement support for `CbFieldType::CustomById` / `CbFieldType::CustomByName`

# Upstream Connectivity

## Jupiter

* High-performance/concurrency HTTP client (on asio)

# Peer Connectivity

* Beacon

# Downstream Connectivity

## Runtime

* High performance HTTP client (layered on asio or UE sockets)

## Cooker

## Editor

## Mirage

# Local Features

* VFS for surfacing debugging information

# TPS

* nodejs/http_parser
* all the rest (do we need TPS for vcpkg packages?)



# Productization

* Incremental cook
* Windows feature complete
* Mac / Linux support
* Non-elevated execution
* State management strategy

# Cache

* M7
 * Cleanup
 * Jupiter upstream configuration

# Editor Domain




# Daemon Notes

When operating in background daemon (Windows Service) mode, there are a few
additional things to consider:

* Install and uninstall (this will vary by platform)
  * Where is the service installed? How is it uninstalled?
* Servicing
  * How is the server versioned? I would suggest going with a single release 
    number to keep things simple. There should not be any tight coupling with
    different engine branches (new releases should be backwards compatible) etc
    and any service development should take place on a single stream