Received-SPF: pass (google.com: domain of linux-wireless+bounces-5275-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 26 Mar 2024 09:51:50 +0100
Message-Id: <D03JY73HKNJ3.2IV95NSJ4PCZS@gmail.com>
Subject: Re: [PATCH v12] 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: <206d1b47b7ece7ccd1c371d23ae1f1c6.legale.legale@gmail.com>
 <f3ab160dd84e936134c6aa60e2f6d0fcf4d61e4c.camel@sipsolutions.net>
In-Reply-To: <f3ab160dd84e936134c6aa60e2f6d0fcf4d61e4c.camel@sipsolutions.net>

On Mon Mar 25, 2024 at 5:32 PM CET, Johannes Berg wrote:
[...]
>
> And that stuff is a really pointless output in JSON, for JSON it'd be
> much more useful to output an object with actual (integer) values, and a
> flag to indicate 'basic', or something.
>
> Anyway ... I think you're hyper-focused on exactly the wrong thing.
>
> Arguably, for scan results, the right thing to do would be to just
> output the raw elements in the JSON, and not do any of this parsing.
> Then you can use your favourite parsing library (dpkt? tshark? ...) to
> actually understand the data there. We really don't need to expose the
> element parsing logic of iw, especially not in a bad way like this.
>
> Also, outputting the *string* data in a machine-readable format like you
> do now has very little value, and yet it ties us to a specific output
> format that we'd probably have to consider stable. Bad idea.
>
> So I guess I'm saying yhou should abandon this line of changes in this
> code entirely.
>
> Much more interesting, IMHO, would be to focus in pretty much anything
> _else_ in the iw code, e.g. the output of 'iw dev', 'iw wlan0 info',
> statistics, etc. Maybe 'iw list' and similar too.
>
> Although I suspect that what we really need is better access for tools
> from nl80211. Maybe the "JSON" output format should just dump the raw
> nl80211 message attributes that are involved, or something.
>

+ 1 on this one. The whole goal of json is to be machine readable, it shoul=
d not
be just be the same output as iw (which is text/user readable) but with jso=
n
syntax / separators insted of \n & \t

> johannes