Handling execution status and execution time in Notebooks #10
Description
Execution status and execution time are two aspects of a notebook that present an interesting edge case for YDocs. They change frequently, but their history does not matter.
Their state does need to be tracked across user sessions, though. For example, if the user executes a long-running cell, closes the document and re-opens at a later time, the execution state, execution time, outputs, etc. all need to reflected accurately.
We could just store these properties in memory of the server. I have a working example of this here: https://github.com/Zsailer/nextgen-kernels-api. However, this requires us to regularly poll the state from the client side to ensure we have an accurate state.
Another approach is to use Awareness to manage these properties, if we make the kernel a client/peer of the YRoom. Awareness is meant to offer a small CRDT for states that do not need to persist across document sessions. If the kernel is also considered a client, then awareness will track these states accurately, even if no browsers (i.e. users) are connected anymore, and keep all clients up-to-date when (re)connected. The question here is whether storing these states in a CRDT will consume too much memory.
I would propose we try to use Awareness to start. If memory becomes an issue, we can likely refresh and flush state frequently in the server and clients without being too disruptive.