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

[Jonathan Maw <jonathan maw codethink co uk>]

On 2019-05-30 08:59, Tristan Van Berkom wrote:
> Hi,
>
> On Thu, 2019-05-30 at 16:39 +0900, Tristan Van Berkom via buildstream-
> list wrote:
> [...]
> >    The frontend really should never be poking it's nose all the way
> >    down into the scheduler's business, this should be communicated to
> >    the frontend more explicitly with an API provided by Stream().
> >
> >    There are multiple reasons for this, but even without process
> >    separation, we should be maintaining the this information and
> >    context is in an API surface crafted for the frontend, we should
> >    have the scheduler updating that and be able to refactor the
> >    scheduler without impacting the frontend implicitly.
>
> The above came out a bit jibberish probably with a rephrase occurring
> without any subsequent proof read :)
>
> Just a little fixup:
>
>   There are multiple reasons for this, but even without process
>   separation, we should be maintaining this information and context in
>   an API surface crafted for the frontend, we should have the scheduler
>   updating that information more explicitly and as a result, be able
>   to refactor the scheduler more freely without implicitly impacting
>   the frontend.
>
> Cheers,
>    -Tristan

Hi Tristan,

I've taken some time to discuss the implementation of separating the UI 
from the scheduler 
(https://gitlab.com/BuildStream/buildstream/issues/1036), and look at 
the information that the frontend uses that will no longer be 
accessible.

Following on from that, I now have a basic plan for how to keep the 
information required for the UI separate from internals.
This basic plan is currently just for how to stop the UI from reading 
the scheduler directly, the next step would be to extend this to storing 
element state (in _frontend/widget.py we look up Elements in the global 
state, which won't be available if we fork before loading elements).

1. Store all state that the UI needs in a single place.

   To this end, I plan to create a _frontend/uistate.py file, which 
contains the classes `UIState` (stores all state, owned by App and 
passed to Status and LogLine so they can read the state), `TaskGroup` 
(as a proxy for queues, stores its name, and lists of active, processed, 
skipped and failed tasks), and `Task` (a replacement for the 
_StatusJob).

2. Define how to change UI state.

   We'll get pretty far by rewriting App._job_started() and 
App._job_completed() to use the UIState instead.
   However, since we're now storing which jobs were skipped, processed 
or failed, we should add to processed or failed depending on the job's 
status.

   We'll need to add a _job_skipped_callback() to report to the frontend 
when a job was skipped, since AIUI a skipped job doesn't call 
_job_started().

   Also, Stream._add_queue() seems to be a good place to add a call to 
the frontend to create TaskGroups. To that end, I'll add a 
queue_create_callback that's passed into Stream and called.

Fingers-crossed, I'll be able to put something together that makes sense 
and have something concrete to show off soon.

Cheers,

Jonathan

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