Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On-demand JSON: A better way to parse documents?

onlinelibrary.wiley.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: On-demand JSON: A better way to parse documents?

#51

Post by bemusedthrow75 »

anonyme-honteux wrote: post #48
bemusedthrow75 wrote: post #38

Earlier quoted context omitted.

> That is, if ` ` is always considered malformed, then why isn't the syntax simply ` `? XML isn't just a structured data format where close tags always run up against each other and whitespace is insignificant. It's also a descriptive document format which is often hand-authored. I think the argument is that the close tags being named makes those documents easier for a human author to understand. It certainly is my e…

Nobody has troubles reading a declarative DSL like Tag1 { Tag2 { } }

We literally have editors that colour bracket pairs to make this stuff easier to deal with, though.

Re: On-demand JSON: A better way to parse documents?

#52

Post by zerocrates »

basil-rash wrote: post #44
zerocrates wrote: post #11

Earlier quoted context omitted.

The one thing I've seen mentioned before is the use of "__proto__" as a object property key. Though it's valid syntax in both JSON and JS like any other string key, it somewhat uniquely does something different if interpreted as JS (setting the created object's prototype) than it does if interpreted as JSON.

That's fair, though somewhat benign barring a prototype pollution vulnerability. The object still behaves the same as it would had you JSON.parse'd the same string (Object.getPrototypeOf aside).

One simple issue would be if your object looks like

x = {"__proto__": {"foo": "bar"}}

now x.foo is "bar" if that's JS code, but undefined if you JSON.parse that same object definition from a string.

Re: On-demand JSON: A better way to parse documents?

#53

Post by beached_whale »

fanseepawnts wrote: post #12

Sorry, I would never use this. Before I consume any json from any source or for any purpose I validate it. Lazy loading serves no purpose if you need validation. Hint: you need validation.

smdjson is validating as it moves through the file

Re: On-demand JSON: A better way to parse documents?

#54

Post by cha42 »

pkulak wrote: post #30

This is a real “why didn’t I think of that” moment for sure. So many systems I’ve written have profiled with most of the cpu and allocations in the JSON parser, when all it needs is a few fields. But rewriting it all in SAX is just not worth all the trouble.

Maybe you need a query engine and not a parser.

Shameless promotion of my beta engine

https://github.com/V0ldek/rsonpath

Re: On-demand JSON: A better way to parse documents?

#55

Post by OnlyMortal »

serial_dev wrote: post #29
eternityforest wrote: post #19

Why not just use msgpack? The advantage of JSON is that support is already built in to everything and you don't have to think about it. If you start having to actually make an effort to fuss with it, then why not consider other formats? This does have nice backwards compatibility with existing JSON stuff though, and sticking to standards is cool. But msgpack is also pretty nice.

Example: you work on the mobile team, the backend team is large and focuses on serving the web app, they send huge JSON payloads that the mobile app only partially need, and asking the backend team to now also serve msgpack is out of the question as things together with the backend and web teams were proven to be a PITA. In this scenario, writing a new, or bundling someone else's json library can significantly improv…

I worked at TomTom on the Home application. There was a similar problem with map updates where the payload was XML.

The devices only needed a sub-range of the XML so I used an XML parser to ignore everything until I got the tag needed then read until the end tag arrived.

This avoided a DOM and the huge amount of memory needed to hold that. It was also significantly faster.

Post reply on HN