For now, new telemetry files are inputted manually by the user. The eventual plan is to automatically read in new telemetry files as they become available.
Although nothing in the application is inherently tied to manual telemetry file input (with the exception of error reporting, which is associated with a yet-to-be-implemented core feature of its own), it's still possible some things may break when the application transitions to live reading, since we didn't necessarily write and test things with asynchronous elements in mind. I suspect a lot of testing may be required here, especially the elements of the application that change whenever new data is read in (and new alarms are generated).
There's already one instance of asynchronous elements not being properly accounted for (provided by Liam):
UI operations are not done under locks, so if a set of alarm checks finish, and the user clicks some UI option simultaneously, unexpected behaviours can occur.
For now, new telemetry files are inputted manually by the user. The eventual plan is to automatically read in new telemetry files as they become available.
Although nothing in the application is inherently tied to manual telemetry file input (with the exception of error reporting, which is associated with a yet-to-be-implemented core feature of its own), it's still possible some things may break when the application transitions to live reading, since we didn't necessarily write and test things with asynchronous elements in mind. I suspect a lot of testing may be required here, especially the elements of the application that change whenever new data is read in (and new alarms are generated).
There's already one instance of asynchronous elements not being properly accounted for (provided by Liam):
UI operations are not done under locks, so if a set of alarm checks finish, and the user clicks some UI option simultaneously, unexpected behaviours can occur.