Re: [PATCH v5] Add JSON output options to 'iw' for scan results

["Nicolas Escande" <nico.escande@gmail.com>]

On Tue Mar 5, 2024 at 10:41 AM CET, Johannes Berg wrote:
[...]
>
> I'm generally not going to look into these files for now, but including
> them internally means we have to maintain them. I'd almost prefer a
> library that can be used.

For what it's worth jansson has been very good to me. It has printf() like
object creation which usually integrates well with c programs.

>
> However, with that said,
>
> > +/*
> > + * json_print.c		"print regular or json output, based on json_writer".
> > + *
> > + *             This program is free software; you can redistribute it and/or
> > + *             modify it under the terms of the GNU General Public License
> > + *             as published by the Free Software Foundation; either version
> > + *             2 of the License, or (at your option) any later version.
>
>
> This doesn't work well with the ISC license of iw. Which is another
> reason to prefer an existing library, I suppose.

With MIT license https://github.com/akheron/jansson/blob/master/LICENSE

[...]

>
> So ... Like I wrote above, generally I'm not against doing this. But
> like I also tried to explain above, I think it needs to be less
> "duplicative". I'm happy to change the code in major ways to make JSON
> output easier, I'm also happy to let that change the output in some ways
> (maybe the default should be YAML-compatible ;-) ).

>
> But I'd really want to see this done in a way that doesn't end up with
> having to duplicate everything all the time.
>

For me, having a "good" json representation means, as you pointed out, using the
right json underlying type and most of the time I'm afraid that means a complete
different code path because of the underlying type/container. It's always a
blurry line obviously but duplicating in a complete seperate function that only
does the right thing for json output may end up being cleaner codewise.

> We'll also need to figure out the licensing situation, and perhaps
> ideally find a way to not add ~1.5k LOC to support it, but link against
> something that exists already.

+1 for not reimplementing the wheel.

>
> johannes