Structured output

[parport0]

The following post is subject to change; all the changes will be reflected below the post with a timestamp and a short summary.

Structured is an idea of decoupling the decoding process from the process of outputting, with the intention of being able to choose between different output "drivers". The main motivation is that the current output format is far from being machine-readable. See project/structured .

The goal of this issue is to document and coordinate the efforts of making strace structured, for people who aren't that immersed in strace development that still might want to contribute, and also for those who still remember the original structured and want to see how it is doing.

An attempt of making strace structured was made several years ago, but the changeset never got merged, as big changesets often do. I argue that all further work should be done upstream, with every change going through the review process and getting merged before more changes based on the given change are prepared.

I personally see structured being implemented in three distinct steps.

• First, abstract all the printing away with PRINT_* macros, implementing more if a need arises.
  • Even though the process of abstracting printing away is already ongoing, there's still a lot of tprint* present in the parsers. There should be none.
• Second, separate the printing part and the parsing part into different compilation units.
  • There is, it seems, a demand for having strace as a library (Compiling strace as a library #70). The output drivers can be seen as different "frontends" in this case. Presenting strace as a library poses a lot of non-structured-related challenges, though.
• Third, implement other output drivers, for example, provide a reference machine-readable output driver. The standard driver can also be consistently modified at this point.

Some, even if vague, vision of the future API is useful at the first step, to have less shuffly-replacey work at the second step. For this reason I would love to hear thoughts on this. Maybe the output drivers should be the libraries instead. Maybe "driver" is not the best name for them. Maybe other backends are already on the horizon and should be taken into account too.

[lefessan]

#228 implements something close, with output in JSON and OCaml formats, that can be chosen at runtime. Other formats could be added easily if they follow the same structure.

[i-ky]

See project/sructured.

The link finds 0 issues. Probably because of missing is:issue in the query. Correct link would be https://github.com/strace/strace/issues?q=is%3Aissue+is%3Aopen+label%3Aproject%2Fstructured (obtained by clicking the label).

[ldv-alt]

This link works as well: project/structured