eclipse-cdt-cloud / trace-server-protocol Goto Github PK

Should the labels be returned as a formatted string? Or wouldn't it make more sense to return it as raw data and let the client format them, by giving it a hint using the dataType and unit (like for the axis data).

For large numbers, like sum of time, it would make more sense as the raw data can be used for sorting, but we can still visualize them in human friendly manner, using the hints. If we decide to go this way, the EntryHeader object will have to be updated to support dataType and units.

What do you think?

PUT for experiments command should not use actions in payload (see below). To add or remove traces provide a list of traces UUIDs in the payload and the server needs to validate whether traces need to be added or removed from the experiment by comparing the lists of traces on the server and in the command

Many model objects have an 'tags' attribute (for example XYSeries, LineMode, and others). The types is often and integer int32, in XYSeries, it's an array of int32.

It's probably related to filters, as the Filter tags description says "Tags to be applied on elements that pass this filter".

• The description of the attributes should specify that those tags match the filter tags specified.

• The /filters endpoint should explain the expected mechanic between filters and tags

• Make sure that the types are OK between int or array of ints

Trees are useful for showing aggregations and summaries, such as statistics. The TSP currently doesn't have a generic API for such data structure.

Things to consider:

• API for trees with columns.
• API to query column descriptors to describe the table column (name/tooltip)
• Align APIs for trees in timegraph, XY etc.

This endpoint can be used to close the experiment and upon reception of the message, the server can dispose can dispose allocated resources. The Trace Compass server will dispose the experiments and close all state system and index files.

Use PUT for this, because sending this message multiple times will have the same outcome. The api should look as follows.

/tsp/api/experiments/{expUUID}:close

Use this notation with :close as suffix, will allow to create dedicated actions for different behaviours, like deleting trace indexes (e.g. delete supplementary files of Trace Compass server, rename, copy etc)

Having such an action will automatically update the gh-pages branch after each update in master branch. This will make sure that the formatted trace server protocol page on https://theia-ide.github.io/trace-server-protocol/ is in sync with master branch.

• What is a gap state?
• How and when they are supposed to created in the server?
• How they are supposed to be used in the client?
• If they are optional or mandatory? (should be optional, right?)
• What happens if they are absent?

The branch gh-pages populates the web-page [1] to provide human readable version of the TSP. After each commit to master master should be automatically merged to gh-pages to avoid manual steps.

[1] https://theia-ide.github.io/trace-server-protocol/

the times[] array being passed in the request body should be defined clearly somewhere as well as the rationale of sending a full list instead of start/end/resolution.

The reason being a server may with to erratically poll an element, and this also allows for several punctual unrelated queries to be sent in aggregation.

It would be interesting to get trace specific one shot data,

e.g. :

• Host Name
• CPU architecture (number of cores/bigLITTLE?)
• System Memory
• GPUs available (number of compute cores?)
• Network config
• Storage config
• Program being traced, if known
• Anything immutable on a given trace (on older systems, frequency)

This information can help with Axes ranges as well as giving more context to the user.

the tsp-typescript-client tries to convert to json any response they get from the server. But some of the error messages, like when putting an invalid trace, return as text strings.

This causes like this in the theia-trace-extension:

Uncaught (in promise) SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
openTrace tsp-client.ts:55
tryOpen trace-manager.ts:76

We should either:

1- Document all error messages to be json, like {message: string} in the protocol and have the server return them this way

or

2- Have the tsp-typescript-client verify the response code before trying to convert to json and have the consumers do likewise whe processing responses

What do you think?

Right now the API for trees in time graph chart, tree xy charts, generic trees (see #19) and virtual table are not aligned. This issues is to track the effort to align and generalize such APIs.

Right now the TSP specification contains currently supported and used APIs as well as proposed APIs.

• It's not clear what is actually used and supported and what is a proposal.
• Split the TSP yaml description into 2 files:

1. Currently implemented and supported APIs
2. Future, proposed APIs (+ APIs of bullet 1)

• Check if https://github.com/swagger-api/swagger-core can be used to automatically generate 1's.

Right now the parentId in the EntryModel is specified as optional and if not present it means that the Entry doesn't have a parent. Being optional has the advantage that it only has to be transported if there is a parent.

In the Trace Compass server reference implementation the parentId is always serialized and value -1 is used to indicate that there is no parent. The theia-trace-extension front-end was aligned to the undocumented special value and handling for value -1.

This tracker is to decide on the wanted specification for the parentId field.

Quote from the GraphQL webpage:

"GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools".

It would be interesting to investigate GraphQL for the TSP as alternative to the REST API that is currently be used, to understand the pros and cons when using GraphQL.