On 13/11/17 11:15, Steffan Karger wrote: [...snip...] >>> You know, the funny thing is that my main reason for implementing JSON >>> support for status was to have it easily _machine_ readable, for higher >>> level programming languages where JSON is "first class citizen", and not >>> primarily human readability. Besides you could easily do this to make >>> JSON human readable: >>> >>> $ cat /path/to/status.json | python -mjson.tool >>> >>> Thinking some more about it now, it doesn't really make sense to >>> implement JSON at all, because CSV _is_ actually meant to be machine >>> readable and a lot more efficient in the amount of data it uses (much >>> less duplication). So it seems my reasons for implementing JSON support >>> seems to completely miss the point. For machine readable output it would >>> make more sense to use a binary format instead of JSON. >>> >>> What do you guys think? Are there any other reasons to implement JSON >>> support? > > This was my original question: why should we *add* JSON? I agree that > if we would have to pick something now, I'd prefer JSON over CSV. But > we already have CSV, and as far as I understand it suffices just fine.
The tooling libraries around JSON vs CSV are more commonly more mature these days for JSON; plus it is so widely used the interwebs are filled with examples. And this does not only go for scripted languages; even there are also nice libraries for C and C++ too, giving you a machine parseable object with better predictability on the result. If I had a project parsing a CSV and had been given a chance to use JSON instead; I'd migrate over ASAP as long as the risks of breaking something badly was not very high (It would depend on where in the call chain such changes happens, and how much happens after that point). So I'm fine with adding --status 4 which dumps JSON. >> Although JSON is a bloated language (meaning that there is lots of >> overhead next to the data itself), I think that it allows you to easily >> extend the objects being sent back and forth with a fairly high chance >> to keep backwards compatibility. >> >> This is barely true for csv. > > The biggest difference is that CSV is 'flat' while JSON is > "hierarchical". But since we already support CSV (and want to keep > supporting it, I guess?), I think we're kind of bound to a flat > structure anyway. Yeah, we cannot rip out CSV now. We could probably propose that further into the future once JSON is widely used. And we could provide some tooling which converts JSON to CSV outside of OpenVPN at that time. >> A binary presentation per se is not bad, but then you need to make sure >> that the format is properly encoded/decoded (especially if the data is >> transferred across the network from/to different platforms) and this can >> be error prone. > > Slightly offtopic: I recently came across CBOR, which seems a good > attempt to merge the benefits of JSON with a binary representation: > https://tools.ietf.org/html/rfc7049 > > Haven't really used it yet though, so no practical experiences > unfortunately. I think that if we want to have a binary approach, that should be a variant of --status 4; like --status 4_binary. >> Honestly I did not read the rest of the thread, but if this data is >> supposed to be exposed through an API (i.e. REST API or any other >> interface) and it is meant to travel across the network, I wouldn't mind >> seeing the JSON format being used. >> >> JSON consumers nowadays are extremely easy to implement compared to others. > > Even compared to CSV? I can't really come up with a situation where I > can consume JSON easily, but can't consume CSV. The library tooling is in my experience far easier and predictable. And the JSON libraries have generally been far better at "object-ifying" JSON to objects you use in your code than what CSV parses have been. But I'll admit, I've mostly avoided CSV for the last decade or so if I could use JSON or even XML. CSV just looks structured - until the layout is changed. While JSON (and even XML for that matter, _not_ saying we should have XML support!) is not strictly bound to the order of fields, so adding new fields is a no-brainer with JSON compared to CSV. And before you say "We only append fields to CSV", some of those changes we have done in the past to --status 3 have even broken some users setup - because the CSV parser was stupid. The risk of that happening to JSON is far less. >> Regarding the JSON "prettiness", I think that printing it in a nice >> readable format makes it just extremely easy to debug and possibly spot >> errors on the fly (even when not searching for them). For this reason >> I'd rather add a couple of tabs and \n to make it easier to read. > > +1, one of the strong sides of JSON is that is easy to make it both user > and machine readable. +1 from me too. Just a few words to the management interface vs --status file. We should support JSON via both channels. And implementing that shouldn't be rocket science as it should be the same function producing that result. But we should consider if we want to make use of a JSON library producing the JSON streams. The reason is to ensure the output is according to the specification and that escaping if contents is consistent and proper. Imagine if someone puts a double-quote into the CN field of a certificate? CN="} Lets explode things, O=Hacktivist0 Or other characters which needs escaping. I also see the proposed patch adds "END" at the very end. To me that makes more sense in text/plain representations to indicate that this is the end of a list of unknown length. JSON have that implicitly with the last '}'. Just my few cents for this round :) -- kind regards, David Sommerseth OpenVPN, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
