The front-end and the back-end communicate with three channels. The
first is the WebSocket connection to the Engine API. Once that
connection is online, a WebRTC connection is negotiated, which contains
one video stream from the server to us for the GUI, and a second, which
is a binary data channel from us to the server, which we send JSON over
for real-time events like mouse positioning.
The lifecycle of the WebRTC connection and the WebSocket connection are
tied, since if the WebSocket connection breaks down, the WebRTC
connection must get restarted (to get a connection to the *same* backend
that we have an open WebSocket connection to).
This starts a move to split the WebRTC and WebSocket pair to be managed
by a new class (EngineConnection), which will only start and maintain
the WebSocket and WebRTC channels. Anything using the EngineConnection
will be able to communnicate commands without needing to add control
logic for the underlying data channels.
Signed-off-by: Paul R. Tagliamonte <paul@kittycad.io>
We can create a enginelessExecutor that can be used for many of the
executor tests that will be much more performant for tests that don't
need the engine to actually do any modeling work.
* Intital async of executor
The execture now sends websocket message instead of calling functions
directly from the engine, When it does so it holds onto the id.
The engine is still returning geo/polys directly but I'm working make it
so that the UI doesn't need to know about that, so that we can switch
over the streaming ui.
Things left to do:
- it is still making both direct function calls and websockets, and the former should be removed.
- It does highlighting of segments and sourceRanges not through websockets and that needs to be fixed.
- Tests have not been adjusted for these changes.
- Selecting the head of a segment is not working correctly again yet.
* Rough engine prep changes (#135)
* rough changes for engine prep
* mouse movements working again
* connect to engine for startsketch, line, close and extrude
