[strace/strace] Structured output (#169)

[Elvira Khabirova]

_The following post is a 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/sructured](https://github.com/strace/strace/labels/project%2Fsructured).

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 of having 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/strace/strace/issues/169
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20210105/286ded46/attachment.htm>