> On Wednesday, March 9, 2016 11:39 AM, "[email protected]" > <[email protected]> wrote:
> > I'd like for the console to be more usable and relevant to quarks > application developers. I'm also hoping by asking for feedback and ideas > for improvements someone may decide they would like to make a contribution to > the console. > 1. Display oplet aliases (application assigned names) instead of the > 'OP_X' in the topology graph > 2. Alternately, remove the 'OP_X' and just assign the index value in the > graph '0', '1', etc Somewhat related to this is there should be a view that represents how a developer coded their application, which is through the topology api, where (for the most part) oplets do not exist. I'm not sure what exactly this would look like, but it's a move away from having oplets as the first class objects, to having streams and windows as the first class objects. Maybe such a graph would look similar but the focus would not be on oplets, e.g. oplet names like OP_1 have no meaning to the application developer. We may in the future have the physical representation (oplets) be heavily transformed from the logical view (topology), so in that case having a logical view is much more useful, e.g. imagine an extreme case where the graph has been optimized down to a single oplet. See: https://github.com/quarks-edge/quarks/wiki/Quarks-Etiao-Runtime > 3. If a topology has counter metrics on all oplets (i.e, DevelopmentProvider > is > used) either a) remove all oplets from the graph or b) make the counter ops > look > less significant or 'grey' them out from the graph. I think there are a number of oplets where the visualization could be simplified, e.g. FanIn, Union Isolate etc. could be not shown in the graph, as they are low-level building blocks somewhat unrelated to the application graph. Dan.
