Live data from Hacker News

Internet Object – A JSON alternative data serialization format

internetobject.org

81–83 of 83 posts

Re: Internet Object – A JSON alternative data serialization format

#81
post #78

Earlier quoted context omitted.

It's silly to not write your software to handle every possible input instead of every input you think is likely based on some predictions about humans. Failure to do that is why YAML is so broken. JSON isn't a format conducive to handwriting even if it probably should have made more accomodations for that at the start. Right now it can't even handle trailing newlines. But if you want to fix that, call it something di…

> Though I'm sure someone's going to step in and say "Have you not heard of [stupendously niche use case]?" > they might hand-edit a machine-generated one to make a change someplace in it Ah, there's [stupendously niche use case] ;) Seriously, though, I do agree with your point that good software should handle every edge case. I'm not arguing that. But the case for having trailing commas does seem to be generally pre…

You also have to think about security implications of a hostile client being able to crash a remote parser with gigabytes of context, though if it crashes on malformed json then they could do that with a much shorter fragment. In the well intentioned case, being paged in the middle of the night to debug a weird crash isn't fun, so it's better to have an accurate diagnosis (version mismatch) in the log if not prevent the crash outright. There is also the matter of every weird javascript implementation that would have to be updated, if JS can't already accept the trailing commas. It just doesn't seem worth hassling over.

Re: Internet Object – A JSON alternative data serialization format

#82
post #79

Earlier quoted context omitted.

> Plus, as I wrote elsewhere, gzipping your JSON will result in essentially "avoiding having to repeat every field name" by dictionary coding it. Gzipping indeed helps in getting mostly back the space taken by the field names, but a parser will still have to parse these strings. On a large document, this might have a performance impact. One good side of having the field names however is that one can reorder them adli…

That's true, but the main argument made by the website is about the space advantage, so it's very relevant that that space advantage is basically nullified by the widespread use of compression. If your worry is parsing speed, then JSON not only has battle-tested parsers, but also has SIMD-assisted parsers which can process gigabytes a second on a single core (e.g. https://github.com/simdjson/simdjson ). It would take…

> If your worry is parsing speed

I am not personally worried by perf in either case, but I see your point.

> It would take Internet Object years to develop parsers as performant as that

Well, implementing a JSON parser is arguably difficult, for many reasons, I suppose the main one is the flexibility it provides. I don't know if this would be the case for this format however. TBH, I doesn't seem to add too much to CSV, and perhaps it would be simpler to use CSV with the first line of this format has a hint for the data structure.

Re: Internet Object – A JSON alternative data serialization format

#83
Hey everyone,

I am the creator of the Internet Object. I have been silently working on the specs. But due to my busy schedule, I was not very active during the past couple of months. It is good to see all of you are discussing the pre-released format! However, I see many people have presumed many things in the wrong context. I want to share the draft of in-progress specs. It will probably bring in more clarity. Recently I have resumed working on this project again. If anyone would like to contribute Internet Object please join the discord channel (Just created).

Specs Draft - https://docs.internetobject.org/ Discord Channel - https://discord.gg/kZ6CD3hF

Thanks and Regards - Aamir

Post reply on HN