<p></p>
<p><em>The following post is a subject to change; all the changes will be reflected below the post with a timestamp and a short summary.</em></p>
<p><em>Structured</em> 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 <a href="https://github.com/strace/strace/labels/project%2Fsructured">project/sructured</a>.</p>
<p>The goal of this issue is to document and coordinate the efforts of making strace <em>structured</em>, 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 <em>structured</em> and want to see how it is doing.</p>
<p>An attempt of making strace <em>structured</em> 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.</p>
<p>I personally see <em>structured</em> being implemented in three distinct steps.</p>
<ul>
<li>First, abstract all the printing away with PRINT_* macros, implementing more if a need arises.
<ul>
<li>Even though the process of abstracting printing away is already ongoing, there's still a lot of <code>tprint*</code> present in the parsers. There should be none.</li>
</ul>
</li>
<li>Second, separate the printing part and the parsing part into different compilation units.
<ul>
<li>There is, it seems, a demand of having strace as a library (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="326874470" data-permission-text="Title is private" data-url="https://github.com/strace/strace/issues/70" data-hovercard-type="issue" data-hovercard-url="/strace/strace/issues/70/hovercard" href="https://github.com/strace/strace/issues/70">#70</a>). The output drivers can be seen as different "frontends" in this case. Presenting strace as a library poses a lot of non-<em>structured</em>-related challenges, though.</li>
</ul>
</li>
<li>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.</li>
</ul>
<p>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.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/strace/strace/issues/169">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AOVBTR44CHO7RMWKREHCKBDSYLTVHANCNFSM4VU2F3SA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AOVBTR6BUYCWO7SMEWOSQJDSYLTVHA5CNFSM4VU2F3SKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4LTMLXIQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/strace/strace/issues/169",
"url": "https://github.com/strace/strace/issues/169",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>