This essentially splits progress into client and sever parts. The client just throws a condition (with the appropriate fields) to signal progress, and the server catches these conditions, reads out the information, and assembles an appropriate progress bar.
The API for this will resemble the RStudio progress bar API, with some small differences.
First, we should be able to create a progress bar id in a subprocess, without consulting the parent process, because that might be a long wait, to get an id from the (potentially busy) parent.
Second, it is probably possible to make the id argument of the update functions (and conditions) optional. If progress bars are embedded into each other, then they form a stack, and if an id is not specified, then it refers to the progress bar on the top of the stack.
API:
list(
command = "add_job",
version = "1.0.0",
name = NULL,
id = NULL,
status = "running",
total = 100,
format = NULL,
estimate = NULL,
auto_estimate = TRUE)
list(
command = "set_job_progress",
version = "1.0.0",
progress,
id = NULL)
list(
command = "add_job_progress",
version = "1.0.0",
increment = 1L,
id = NULL)
list(
command = "set_job_status",
version = "1.0.0",
status,
id = NULL)
list(
command = "set_job_estimate",
version = "1.0.0",
seconds,
id = NULL)
list(
command = "complete_job",
version = "1.0.0",
succeeded = TRUE,
output = NULL,
error = NULL,
id = NULL)
We also need to be able to signal the termination of subprocesses, so that the event loop or other subprocess manager does not have to know about the progress protocol.
This essentially splits progress into client and sever parts. The client just throws a condition (with the appropriate fields) to signal progress, and the server catches these conditions, reads out the information, and assembles an appropriate progress bar.
The API for this will resemble the RStudio progress bar API, with some small differences.
First, we should be able to create a progress bar id in a subprocess, without consulting the parent process, because that might be a long wait, to get an id from the (potentially busy) parent.
Second, it is probably possible to make the
id
argument of the update functions (and conditions) optional. If progress bars are embedded into each other, then they form a stack, and if an id is not specified, then it refers to the progress bar on the top of the stack.API:
We also need to be able to signal the termination of subprocesses, so that the event loop or other subprocess manager does not have to know about the progress protocol.