Re: [BuildStream] Responsive, but not overly verbose UX - not-in-scheduler

[Jonathan Maw <jonathan maw codethink co uk>]

On 2019-05-29 08:34, Tristan Van Berkom wrote:
> Hi Jonathan,

[snip]

> As far as I can see, rushing forward to implement this early logging
> both:
>
>   * Potentially regresses architectural corrections we made by ensuring
>     that we do *not* have any dual standards/codepaths for logging.
>
>   * Adds more burden to the larger task of process separation by adding
>     yet more codepaths to deal with in this separation, instead of
>     standardizing on a common API path for logging.
>
> Please reconsider this.
>
> Cheers,
>     -Tristan

Hi Tristan,

Thanks for your architectural concerns, I wouldn't want to cause 
architectural regressions here, either.

Do I understand correctly that the correct standard logging path for 
reporting progress here would be in `Context.message()`?

Also, based on what I know about the work to make the UI run in a 
separate process, I think that will cause there to be a regular frontend 
running at the point where we're loading elements. Would it be enough 
here to make sure that I keep in discussion with the people working on 
!1038 to make sure I'm using the same codepath as them, or are there 
other details I haven't taken into account?

It sounds like reporting when we load a junction will be tricker than I 
guessed. I'll make sure I'm on the same page as the people working on 
!1038, and have a look at whether Scheduler needs any work to run 
`Scheduler.run()` repeatedly in a clean way.

Thanks,

Jonathan

--
Jonathan Maw, Software Engineer, Codethink Ltd.
Codethink privacy policy: https://www.codethink.co.uk/privacy.html