3 ms·

Why not throw in the inline comments feature to the mix if you're gonna end up using a different spec/different parser anyway? This is an 8+ year old spec and I

by alpb 5y ago

Why not throw in the inline comments feature to the mix if you're gonna end up using a different spec/different parser anyway? This is an 8+ year old spec and I don't think it has caught much adoption. If you're really into hot having commas, maybe you can do a post-processing step with sed or in-memory string replacement to add/remove "," and \n? Then you're still getting the same JSON experience under the covers where programs process it?

wolfgang42 5y ago
The idea behind this spec is that it’s an ultra-simple framing format for a stream of JSON documents; you would use the same JSON parser as always but e.g. inside a loop that reads each line from the input. It has lots of adoption, but since it’s such a simple format many of those have invented it independently and don’t call it by name.
laurencerowe 5y ago
> Why not throw in the inline comments feature to the mix if you're gonna end up using a different spec/different parser anyway? Doing so would complicate adoption, since parsing is essentially just: for line in file: obj = json.loads(line) > This is an 8+ year old spec and I don't think it has caught much adoption It's seen huge adoption, essentially becoming the standard logging format for many Node JS applications. Usually I've heard it referred to as JSON Lines: https://jsonlines.org https://jsonlines.org
- nerdponx 5y ago
  The name "JSON Lines" is a lot better in my opinion. I hope the two Git repo maintainers can agree on some kind of merge, but they've had almost a decade to do it and neither one seems interested. There's also an RFC (7464) for more or less the same thing, except using ASCII record separators instead of newline characters: https://datatracker.ietf.org/doc/html/rfc7464 https://datatracker.ietf.org/doc/html/rfc7464 And yes, I have used this at $JOB and I intend to use it in future ${JOB}s. That's adoption.
  - laurencerowe 5y ago
    Big advantage of using new lines over record separators is that you can use standard unix command line tools. Can get a long way with grep | jq | sort | uniq pipelines.

by alpb 5y ago

wolfgang42 5y ago

The idea behind this spec is that it’s an ultra-simple framing format for a stream of JSON documents; you would use the same JSON parser as always but e.g. inside a loop that reads each line from the input. It has lots of adoption, but since it’s such a simple format many of those have invented it independently and don’t call it by name.

laurencerowe 5y ago

> Why not throw in the inline comments feature to the mix if you're gonna end up using a different spec/different parser anyway? Doing so would complicate adoption, since parsing is essentially just: for line in file: obj = json.loads(line) > This is an 8+ year old spec and I don't think it has caught much adoption It's seen huge adoption, essentially becoming the standard logging format for many Node JS applications. Usually I've heard it referred to as JSON Lines: https://jsonlines.org https://jsonlines.org

nerdponx 5y ago
The name "JSON Lines" is a lot better in my opinion. I hope the two Git repo maintainers can agree on some kind of merge, but they've had almost a decade to do it and neither one seems interested. There's also an RFC (7464) for more or less the same thing, except using ASCII record separators instead of newline characters: https://datatracker.ietf.org/doc/html/rfc7464 https://datatracker.ietf.org/doc/html/rfc7464 And yes, I have used this at $JOB and I intend to use it in future ${JOB}s. That's adoption.
- laurencerowe 5y ago
  Big advantage of using new lines over record separators is that you can use standard unix command line tools. Can get a long way with grep | jq | sort | uniq pipelines.