Eclipse Theia trace viewer extension using the Trace Server Protocol (TSP), through the tsp-typescript-client. Also the home for reusable JavaScript libraries: traceviewer-base, traceviewer-react-components
If while the user navigates on the theia-trace-extension, either the trace server or the theia backend is shut down, the UI should handle the absence of server correctly and reconnect when it is coming back
XY Component is using ChartJs wrapped in a react-chartjs-2 library. We should create our own instead of using the library. It's not hard to do and will offer way more flexibility to change the axis, draw over the chart and add plugins to chartjs. This should be looked into before subsequent tasks as it may have an impact on how to solve them. Some problems occur when panning. Observe what is happening, that shouldn’t be.
It should be possible to navigate the time graph in a fast seamless way, no matter the size of the trace. Any performance issue observed should be improved.
XY Component should use a custom axis instead of the one used right now. Custom axis are supported in ChartJs and the axis created should take all the information needed from the "universal" time axis
The data on the theia frontend should be filterable and searchable
Add the ability to filter and search: a box somewhere to send the query to the server
Survey other tracing/monitoring frontend to see how they do filters
Show active filters, enable/disable them. A lot of web app have such nice UX for those filters
In the Trace Compass incubator is a language server for the filters, it can be used to make global filters and searches in Theia, which would filter all the opened viewers
Add a filter builder interface? given the outputs that are opened, pre-fill some fields. Should this kind of filter be done client-side too? Needs some thinking
When one of the calls to the trace server returns with an error, the theia frontend should handle it properly, either by doing the appropriate actions to fix it (post again, re-post the trace, etc), or add the error to the status bar at the bottom so the user can see why an output is not shown or what he expected did not happen.
The frontend should also handle when the trace server is not online
For now, the trace server supports only one user. But eventually, it should support more than one, many users can open the same trace/experiment at once. Keep track of who have the trace opened and delete the traces from server only when all users have stopped using it.
The various Theia outputs now open at the full width of the trace viewer and with a fixed height. It should be possible to resize and move all outputs. The layout used, the react-grid-layout, should provide everything needed to do this (https://github.com/STRML/react-grid-layout)
The time-axis used is part of the timeline-chart library. It should be moved in a separate library so that it can be reused (eg for XY charts) and updated separately. The time-axis is the basis for navigation: zoom in/out, show the current time range.
There is a unit controller "TimeGraphUnitController in the timeline-chart library that control the "time" and a "TimeAxisComponent" that use the unit controller to draw the axis
Maybe everything can stay in the timeline-chart library or can be split into different components that can be added as dependencies
The time-axis also has a visual representation. Be creative ;-) Lttng-scope had an interesting approach
Currently to know if an analysis is completed, it uses fetchTree() to get the status. This is bad since fetchTree() can be a long call. Need to use OutputDescriptor at some point or other better way (maybe Server-side events)
Add to the TSP a way to send extensions to the server, retrieve and execute them. This, along with everything that involves the TSP will require a more thorough review, maybe on mail on the mailing list.
Have the Trace Compass Server implement the extension for scripting
Have the Trace Compass Server implement the extension for XML analysis
Allow any extension to be overwritten
Support providing extension from the theia frontend
The Trace Compass Incubator supports scripting in Javascript and Python. Part of those scripts are UI specific and should be run on the client (that should be implemented differently than in Eclipse), other part are data-specific, so should be run in the server backend (common)
Package EASE plugins so that there can be core-only features (require modification on the Eclipse EASE project)
Package the Trace Compass feature as core-only features (those are features in the incubator)
Support the core-only functionalities (for example script-defined data providers) in Theia.
Test more complex use cases, involving UI-side or python third-party libraries features.
Some data providers provider styles for the series, containing the type of series, or colors. They should be taken into account when possible. Otherwise, the xy charts should provide nice defaults if no styles are available.
Propose for discussion a mechanism to pass possible actions from the server. Or maybe we miss something entirely if we think we need such a mechanism? Anyway, see example actions below, maybe look at other web software for interaction between views ideas.
Some views in Trace Compass have specific actions, for instance the entry filters, follow threads from the control flow view to get the critical path, etc. We should think about how to support those actions from Theia.
Propose a mechanism to suggest actions on data and how to execute those actions
To find traces programmatically in the file system where the source code (language server) is. For this I'd like to issue a command on a folder and search for file/directories with a given file pattern. For example:
"From a start directory, find all files with the file suffix *.log"
"From a start directory, find all directories that contains a file called metadata"
Sending "long" times using JSON number is a potential problem to any javascript or any language that doesn't support big integer. It will work in Theia if we use BigInt, but not in other frontend if the dev doesn't or can't support BigInt.
Sending as string might impact the size or the response but need to test if it really does something. The advantage is that the frontend can convert that string in something that can be useful
We can either force BigInt in TSP or use String
NodeJS 10 and Chrome supports it, (JavaScript version?)
On basic installations, there may not be a trace server running separately from theia. Admins need to make sure such a server exists and is started. The Theia default installation should include fetching and starting the web server.
The trace server should also be configurable, so if there's a remote server running, it should all point to it.
That means when we navigate a trace, it saves the current context: visible time range, selection, opened views, the visible entries in each view, etc. Context can be shared, i.e. we can copy paste some kind of url that we can send to a colleague to see the same “view” of the system.
Note that the trace server itself is stateless, so the context data should be saved in the theia server backend.
Develop the classes to save the current context stack
Time ranges and current outputs are a good first start for the context
As the user navigate, save a stack of the current context
Add the whole context to the copy-paste URL of a trace, so the person who will open the link will directly arrive at the same context
Save the "state" of the frontend to not lose the current work when you refresh the browser
Add the possibility to undo/redo. Find some key binding (ctrl-z/ctrl-y in a browser? Some other standard for that kind of application?) and stack/unstack contexts to go back to previous context
Look if there are any browser standard fro that kind of context: for example snowflake
Test that all actions supposed to change the context do so correctly and can be done/undone
Some data providers, like the Open Tracing span view, have annotations to display in the time graph view (they are typically additional symbols to put at certain entries/time ranges). They should be displayed in the time graph