Tues May 28: HO, BK, DS, MR present
- task proxies and the task pool in the workflow service
- what ghost nodes are in the graph view: tasks at that cycle point that currently have no associated task proxy at the back end
- tree and dot views do not currently show “ghost tasks” but should. Users should not be expected to understand the difference between a waiting task at cycle point N and one that does not exist yet (because that task proxy has not spawned beyond cycle point N-1 yet)
In cylc-7 only the graph view uses the graph data, and it colours is nodes that have corresponding task status data - any remaining un-coloured nodes are ghost nodes. Other views just take a list of all tasks that reflects the task proxy pool at the back end (with ghosts missing).
Cylc can have tasks with different cycling intervals in the same workflow, so we can’t just assume that every task appears in every cycle point. It is the graph determines what tasks are possible in each cycle point.
The graph is presented as a flat list of edges, i.e. pairs of connected nodes. Graph libraries construct the graph from the edges.
To have ghost tasks in all views, all views will need the graph data (edges) client-side, or the graph data will need to be consulted server-side to add ghosts to the task status data (probably the latter?).
So: ghost tasks should be pretty easy in the new UI.
DS also commented, on GraphQL:
- queries can return a flat list of task data, which could be used to construct the tree view client side, OR a nested family tree structure that might be able to feed the tree view directly (the family tree depth has to be
known in this case, to construct the query).
- it is possible to get from graph edges do task data, so if using the graph client-side we would not necessarily need to separately retrieve the graph and the task proxies.
- need to stop user “TaskProxy” in the GraphQL schema, because it doesn’t have the same meaning as in the server program.
Can we get DS’s PR merged soon as possible, to use as a basis for further development? OS’s problems with it may not matter much as switching out Protobuf, or not, is pretty easy, and protobuf and GraphQL work perfectly well together (if we have GraphQL at the WS too).
Incremental updates still TBD.
- fairly straightforward for WS-UIS?
- but what about UIS-UI?