Define the countertop API #82
Comments
|
Note: for the purposes of this phase I think we should not design around Docker. I would like to consider creating some Docker / Appliance utilities, including a root Docker image that all appliances buld from in their docker files, and a parallel We talked a fair amount in #65 about the desire to not have appliances be dependencies of this repository, and moving to having instance repositories of TV kitchen that define an individual countertop topology. This means that the countertop API will not load appliance packages directly since it won't have access to the modules directly. With that model I immediately see two ways an appliance could be registered in the countertop:
In theory both of these paths could work. The benefits of registering instances
The benefits of registering prototypes
Note: I think we would need to create a
Right now I am leaning towards the more flexible (but potentially more verbose) architecture of registering prototypes as a first step. |
|
All right, how about this:
This still allows us to create appliances on demand without relying on half baked non-features such as cloning, but feels a bit more intuitive because adding an appliance does not become a two step process. EDIT: I had originally suggested |
This adds everything required to generate countertop topologies, where a toplogy represents the network of data streams that make up the actual byproducts of the TV Kitchen. This commit introduces some core concepts: 1. CountertopCoordinator, which is the primary entry point of the countertop for developers who are creating a TV Kitchen instance. 2. CountertopStation, which houses a single type of configured appliance. A given station might have more than one active copy of that appliance, in order to support more than one distinct data stream. 3. CountertopStream, which is a thread of data that is being processed and tranformed by various appliances / stations. There will be additional countertop concepts (e.g. the worker) but the scope of this commit is simply to allow someone to register appliances with the countertop and have the countertop generate the toplogy of those appliances (streams and stations). Topologies are basically a graph where vertices are stations, and edges form paths which are captured by Streams. We store one stream per cumulative path (so A, and A => B, A => B => C would each get a distinct stream). See issue #23 for a discussion on various topology examples that this algorithm would generate and support. Issue #23 Issue #30 Issue #82 Issue #6
This adds everything required to generate countertop topologies, where a toplogy represents the network of data streams that make up the actual byproducts of the TV Kitchen. This commit introduces some core concepts: 1. CountertopCoordinator, which is the primary entry point of the countertop for developers who are creating a TV Kitchen instance. 2. CountertopStation, which houses a single type of configured appliance. A given station might have more than one active copy of that appliance, in order to support more than one distinct data stream. 3. CountertopStream, which is a thread of data that is being processed and tranformed by various appliances / stations. There will be additional countertop concepts (e.g. the worker) but the scope of this commit is simply to allow someone to register appliances with the countertop and have the countertop generate the toplogy of those appliances (streams and stations). Topologies are basically a graph where vertices are stations, and edges form paths which are captured by Streams. We store one stream per cumulative path (so A, and A => B, A => B => C would each get a distinct stream). See issue #23 for a discussion on various topology examples that this algorithm would generate and support. Issue #23 Issue #30 Issue #82 Issue #6
This adds everything required to generate countertop topologies, where a toplogy represents the network of data streams that make up the actual byproducts of the TV Kitchen. This commit introduces some core concepts: 1. CountertopCoordinator, which is the primary entry point of the countertop for developers who are creating a TV Kitchen instance. 2. CountertopStation, which houses a single type of configured appliance. A given station might have more than one active copy of that appliance, in order to support more than one distinct data stream. 3. CountertopStream, which is a thread of data that is being processed and tranformed by various appliances / stations. There will be additional countertop concepts (e.g. the worker) but the scope of this commit is simply to allow someone to register appliances with the countertop and have the countertop generate the toplogy of those appliances (streams and stations). Topologies are basically a graph where vertices are stations, and edges form paths which are captured by Streams. We store one stream per cumulative path (so A, and A => B, A => B => C would each get a distinct stream). See issue #23 for a discussion on various topology examples that this algorithm would generate and support. Issue #23 Issue #30 Issue #82 Issue #6
This adds everything required to generate countertop topologies, where a toplogy represents the network of data streams that make up the actual byproducts of the TV Kitchen. This commit introduces some core concepts: 1. CountertopCoordinator, which is the primary entry point of the countertop for developers who are creating a TV Kitchen instance. 2. CountertopStation, which houses a single type of configured appliance. A given station might have more than one active copy of that appliance, in order to support more than one distinct data stream. 3. CountertopStream, which is a thread of data that is being processed and tranformed by various appliances / stations. There will be additional countertop concepts (e.g. the worker) but the scope of this commit is simply to allow someone to register appliances with the countertop and have the countertop generate the toplogy of those appliances (streams and stations). Topologies are basically a graph where vertices are stations, and edges form paths which are captured by Streams. We store one stream per cumulative path (so A, and A => B, A => B => C would each get a distinct stream). See issue #23 for a discussion on various topology examples that this algorithm would generate and support. Issue #23 Issue #30 Issue #82 Issue #6
This adds everything required to generate countertop topologies, where a toplogy represents the network of data streams that make up the actual byproducts of the TV Kitchen. This commit introduces some core concepts: 1. CountertopCoordinator, which is the primary entry point of the countertop for developers who are creating a TV Kitchen instance. 2. CountertopStation, which houses a single type of configured appliance. A given station might have more than one active copy of that appliance, in order to support more than one distinct data stream. 3. CountertopStream, which is a thread of data that is being processed and tranformed by various appliances / stations. There will be additional countertop concepts (e.g. the worker) but the scope of this commit is simply to allow someone to register appliances with the countertop and have the countertop generate the toplogy of those appliances (streams and stations). Topologies are basically a graph where vertices are stations, and edges form paths which are captured by Streams. We store one stream per cumulative path (so A, and A => B, A => B => C would each get a distinct stream). See issue #23 for a discussion on various topology examples that this algorithm would generate and support. Issue #23 Issue #30 Issue #82 Issue #6
This adds everything required to generate countertop topologies, where a toplogy represents the network of data streams that make up the actual byproducts of the TV Kitchen. This commit introduces some core concepts: 1. CountertopCoordinator, which is the primary entry point of the countertop for developers who are creating a TV Kitchen instance. 2. CountertopStation, which houses a single type of configured appliance. A given station might have more than one active copy of that appliance, in order to support more than one distinct data stream. 3. CountertopStream, which is a thread of data that is being processed and tranformed by various appliances / stations. There will be additional countertop concepts (e.g. the worker) but the scope of this commit is simply to allow someone to register appliances with the countertop and have the countertop generate the toplogy of those appliances (streams and stations). Topologies are basically a graph where vertices are stations, and edges form paths which are captured by Streams. We store one stream per cumulative path (so A, and A => B, A => B => C would each get a distinct stream). See issue #23 for a discussion on various topology examples that this algorithm would generate and support. Issue #23 Issue #30 Issue #82 Issue #6
This adds everything required to generate countertop topologies, where a toplogy represents the network of data streams that make up the actual byproducts of the TV Kitchen. This commit introduces some core concepts: 1. CountertopCoordinator, which is the primary entry point of the countertop for developers who are creating a TV Kitchen instance. 2. CountertopStation, which houses a single type of configured appliance. A given station might have more than one active copy of that appliance, in order to support more than one distinct data stream. 3. CountertopStream, which is a thread of data that is being processed and tranformed by various appliances / stations. There will be additional countertop concepts (e.g. the worker) but the scope of this commit is simply to allow someone to register appliances with the countertop and have the countertop generate the toplogy of those appliances (streams and stations). Topologies are basically a graph where vertices are stations, and edges form paths which are captured by Streams. We store one stream per cumulative path (so A, and A => B, A => B => C would each get a distinct stream). See issue #23 for a discussion on various topology examples that this algorithm would generate and support. Issue #23 Issue #30 Issue #82 Issue #6
Task
Description
We have an issue already for creating the countertop (#23) and two issues that talk about the need for an API to communicate with the countertop (#65 and #66).
This issue is a blend of a discussion issue and a task; I would like to use it to define the initial developer API for the countertop. This is the API that developers will use to do things like:
Relevant Resources / Research
None
Related Issues
The text was updated successfully, but these errors were encountered: