Create countertop topology generation

slifty commented 4 years ago

Description

This PR adds the first portion of the countertop, which is the central workspace of the TV kitchen ultimately responsible for setting up the appliances and data streams to process all unique data streams.

Specifically, it adds the countertop components necessary to register appliances and convert a set of registered appliances into a data flow topology (the various data paths between sections of the countertop which will transform that data into new formats).

This begins to implement some of the API described in #82.

Since this is the first countertop PR, it defines a few key classes which will be expanded on in future PRs:

CountertopCoordinator defines the developer API -- developers will be working with this entity directly. It is where new appliances are registered. It generates the rest of the countertop.
CountertopStation represents a section of the countertop dedicated to a single configured appliance. There will likely be more than one copy of a given appliance (one copy per data stream).
CountertopStream is an object that is used to (A) determine how many appliances should exist in a given station and (B) determine which appliances should process a given payload.

Issue #23 goes through a fair number of example topologies.

This PR does not completely finish the countertop, but rather it creates the API for registering appliances and converts a list of appliances into a topology which the countertop will use to set up stations and route packages between stations.

Due Diligence Checklist

[x] Tests
[x] Documentation
[x] Consolidated commits
[x] Relevant labels assigned

Steps to Test

The best way to test this is using your _sandbox.js

Here's an example sandbox:


import { IAppliance } from '@tvkitchen/base-interfaces'
import CountertopCoordinator from '%src/components/countertop/CountertopCoordinator'

class SourceAppliance extends IAppliance {
    static getInputTypes = () => []
    static getOutputTypes = () => ["STREAM.CONTAINER"]
}

class CaptionAppliance extends IAppliance {
    static getInputTypes = () => ["STREAM.CONTAINER"]
    static getOutputTypes = () => ["TEXT.ATOM"]
}

class LineAppliance extends IAppliance {
    static getInputTypes = () => ["TEXT.ATOM"]
    static getOutputTypes = () => ["TEXT.LINE"]
}

class ComplexAppliance extends IAppliance {
    static getInputTypes = () => ["TEXT.LINE", "STREAM.CONTAINER"]
    static getOutputTypes = () => ["IMAGE.FILE"]
}

const countertop = new CountertopCoordinator()
countertop.addAppliance(SourceAppliance)
countertop.addAppliance(SourceAppliance)
countertop.addAppliance(CaptionAppliance)
countertop.addAppliance(LineAppliance)
countertop.addAppliance(ComplexAppliance)
const topology = countertop.updateTopology()
console.log(topology)

Deploy Notes

None

Related Issues

Related to #23
Related to #30
Resolves #82
Resolves #65

slifty commented 4 years ago

@chriszs This is not final, but what's in here is ready for review. Specifically the toplogy generation.

I'm going to be adding tests and documentation, but 85% of the complexity of the PR is already in here.

slifty commented 4 years ago

All right -- I am going to merge this despite not reaching perfect self-documented clarity because:

1) It may change fundamentally some day anyway 2) It does have an appropriate level of documentation (e.g. all methods are documented), and explaining the overall algorithm may be better suited for the website documentation page.

tvkitchen / countertop