Received-SPF: pass (google.com: domain of linux-wireless+bounces-4372-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 05 Mar 2024 11:17:53 +0100
Message-Id: <CZLQMMSSUWBF.1NPJJYDRIXGIR@gmail.com>
Subject: Re: [PATCH v5] Add JSON output options to 'iw' for scan results
From: "Nicolas Escande" <nico.escande@gmail.com>
To: "Johannes Berg" <johannes@sipsolutions.net>, "Isaev Ruslan"
 <legale.legale@gmail.com>, <linux-wireless@vger.kernel.org>
References: <5c5be485dcfceb44fc731e47758d6be3.legale.legale@gmail.com>
 <12f91b008d6f2b4e6241794d2852c1c84fe6c12c.camel@sipsolutions.net>
In-Reply-To: <12f91b008d6f2b4e6241794d2852c1c84fe6c12c.camel@sipsolutions.net>

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 Lic=
ense
> > + *             as published by the Free Software Foundation; either ve=
rsion
> > + *             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, usin=
g the
right json underlying type and most of the time I'm afraid that means a com=
plete
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