There's a lot that we can potentially do with the progress meter API, but initially the important goals are (1) having the simplest API give the most reasonable behaviour possible (2) composability, so that package authors can use it without worrying about how their code will be used.
The basic API shouldn't be too controversial:
@progress [name] for ...
Since this is completely opaque it gives us freedom to do whatever we want under the hood in terms of estimating times, aggregating nested bars into a single one, guarding against overly-frequent updates which might slow the computation down and so on.
The way I initially see this working on the frontend side is very simple: the idea is simply to have a "stack" of progress bars (mirroring the stack that's displayed) and push and pop new bars from the top. I think this would provide the most useful behaviour in the most cases. When progress bars are nested, longer running ones that represent the whole computation will tend towards the bottom, and you can hover over to see more detail about what's going on. This design also covers more advanced cases that would be impossible to aggregate automatically, like a main loop spinning off multiple concurrent sub-loops.
If you do have something like that, you can use a lower-level API for more control. Something like the following should give the user enough capability without limiting our implementation:
p = ProgressBar([name])
Creating the progress bar object avoids the problems of an implicit global bar, and we can always add more methods to it if need be.
Currently, I don't see getting the lower-level API out as a priority vs just having
@progress work, unless there's a really good use case for it that I'm missing.
There was also a question of whether the front or back end should be responsible for things like updating ETAs. Personally, I see the ETA as being "view" information derived from the raw data, so having the frontend be responsible makes sense and potentially makes it easier to make the view more fancy. But that's a detail that can change easily.
cc @pfitzseb who has been working on this already, and @ChrisRackauckas as our first user. What do you think?