[GSOC2015] JSON Formatting

[Philippe Ombredanne]

On Tue, Mar 3, 2015 at 4:00 PM, Louis Feuvrier <louis at feuvrier.org> wrote:
> Hi everyone,
>
> My name is Louis Feuvrier and I'm a student at EPITA, a computer science
> school in Paris. I have been working on low-level problems for most of
> my time at school now and always felt drawn to open source development.
> I've wanted to contribute to something useful to others.
>
> The proposal about re-working on the JSON output formatting interests
> me. It feels like an abstraction problem that I can manage. What also
> seduced me about this project is that the code base is still relatively
> small, and would allow me to grasp a lot of the logic pretty early on.
> The fact that it is widely used is also a great argument for me.
>
> I have taken steps in understanding more accurately the problem at hand
> by downloading the (quite consequent) patch from Zhu YangMin and taking
> a look at it.

Excellent start!
FWIW (quite consequent) made it difficulty to process.

> Thus far, I feel like the abstraction is not quite there.

Agreed, this is not a simple thing.

> However, as I have not dived as deep as Zhu, I am not sure up to what
> point my idea of abstracting the whole {t,j}print{f,s} output functions is
> feasible.
> I have to say that the output formatting logic in the middle of the
> general code path is verbose to say the least.

Your are on the right track.
I think a better abstraction is possible and that would be the major win here.
Beyond eventual JSON support, the whole codebase would benefit from this.

> Regarding the work to do aside from the one already achieved by Zhu,
> what exactly are the code paths not covered? I would like to know more
> about it before drafting my proposal.

You would have to dive in the previous work there.
I think that one of the reason it did not make it in the main codebase
is in part because the changes are wide ranging and it is hard to
review such a massive patch at once.
A better way (which requires much more work of course) would be to
come with smaller incremental patches and clearly separate the parts
that are JSON-specific for later, focusing first on an incremental
refactoring and abstraction of the printf scattered code.
Even if JSON support is not ultimately completed, that would be a much
easier to incrementally integrate and would have value of its own.
And would pave the way for JSON support eventually.
And this should be supported by plenty of (new) unit tests as you go, of course.

So IMHO a good proposal would go at this in small steps:
- find a best approach abstract printing in abstract of any JSON
output and submit these as small incremental and consistent patches.
This should introduce no new feature.
- once and if that can be completed, implement JSON support, if possible
- bonus for setting up a simple CI, with travis, drone or similar to
support sanity as you go.

BTW, the line-by-line JSON approach has names and even specs now!
See [3] , [4] and [5]

One thing would be also to consider using only lowercase identifiers
in JSON objects as opposed to mixed case names.
That is a detail, but an important one (at least to me).
And finding good and meaningful field names will be important: this is hard.

> I'm trying to read-up on the mailing list and the decisions taken last
> year as part of the GSOC2014. If you know how to retrieve a more
> text-based and readable version of the archive, I would be glad to
> know about it as well.

Check [6] . For instance with [7]  you would download the 3528/3530
messages range.
JSON-related emails should likely be in the 3432 to 4070 range.
Update the URL as needed.
That and Zhu's repo @ [8] should get you going (but you already had found it)

> You can get to know more about me on my modest webpage[1]. My most
> recent work as a developer and Teaching Assistant of my school's kernel
> course and exercises is unfortunately only partially viewable[2], as
> some parts of it are used as correction material.

> [1] http://louis.feuvrier.org
> [2] http://git.lse.epita.fr/?p=stos-student.git;a=summary

That's plenty to chew on for us!
I have also checked out [9]

[3] http://jsonlines.org/
[4] https://github.com/ndjson/ndjson-spec
[5] http://en.wikipedia.org/wiki/Line_Delimited_JSON
[6] http://gmane.org/export.php
[7] http://download.gmane.org/gmane.comp.sysutils.strace.devel/3528/3530
[8] https://github.com/zym0017d/strace_GSOC
[9] https://bitbucket.org/m4nny/

-- 
Cordially
Philippe Ombredanne