David Sutherland

> Just thinking now that we may want to put them in a separate dir to the one used for cylc gui files? Since we are reusing guis (and updating...

> I don't fully understand the issue of implementing this comms method - would any uiserver info be suitable, or do we need the particular uiserver that the workflow will...

> They don't get cleaned when cylc gui/hub is not shut down cleanly, e.g. killed with a kill -9. Also, they are not cleaned up when stopping the UIS via...

From the face of it options (2)-(5) are my preference, motivation: - If we want to create our own ZeroMQ GraphqQL subscriptions then we can at least have the knowledge/experience...

> > From the face of it options (2)-(5) are my preference, motivation: > > Completely agree. > > I'm leaning towards (2). > . > . > . >...

Overarching task can be split into two: 1. Upgrade `cylc-flow` end to use latest graphql-core and graphene, including null-stripping and related middle-ware. 2. Develop UIS solution to integrate graphql-core/graphene with...

> I think we've got a way forward now so I'll remove that question label. Do you want to self-assign this issue? Yes, done.. Already made a start on the...

`cylc-flow` end done: https://github.com/cylc/cylc-flow/pull/6478

> Presently, the UIS subscribes to all topics for all active workflows Well, no, just two topics .. `all` (which is all data), and `shutdown`... (also, `shutdown` should always be...

I don't think it should be `updated`, the UI should rebuild it's store on: - Start - Reload - UIS resync (due to failing validation) Main reason being; there may...