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 should not be just be the same output as iw (which is text/user readable) but with json syntax / separators insted of \n & \t > johannes
