41–50 of 57 posts
It's not just the extra compute, it's the lack of a formal specification. If different services applied this kind of ad hoc "postel's principle" they may parse the malformed markup differently, and end up introducing downstream inconsistencies.
Please don't do things like this. It only encourages people to be lazy about producing conforming documents, and different parsers that try to compensate for syntax errors are going to do so in different ways. We learnt this the hard way with HTML.
Why would a JSON file be GBs in size? I think that's the more interesting question.
Because it has GBs of data? There's no size limit on JSON.
Appropos escaping, people are most likely to do this if they never wrote PHP websites as kids and never went through `urlencode` and `mysql_escape_string` hell.
Great, after the tag soup of modern browsers are we now also going to see json soup? Sometimes it's obvious what's wrong with malformed data you receive. A classic would be encoding errors. But as soon as you start supporting broken components and APIs, you will never be able to unsupport it. Prime example would be HTML. Granted, in the beginning, it was supposed to be written by humans but that was rather quickly no…
I've written a relatively popular Atom/RSS feed parser for Go [0]. I struggled with this very issue but I ultimately ended up attempting to be robust against out-of-spec feeds. A super strict feed parsing library is less useful than one that can successfully parse certain classes of broken feeds. It is a fine line to walk -- I won't add a great deal of complexity to support overly broken feeds, but if it is relativel…
So it was pretty robust but yeah, somewhere you should draw the line.
I think, as long as it doesn't compromise the design of your program (for example, parsing rfc822 dates with localized weekdays) it's fine to be a bit lenient in what you accept.
Anything that goes beyond, needs a very good reason.
Why would a JSON file be GBs in size? I think that's the more interesting question.
Maps. [0] Geo-cordinate data can consist of tens of thousands of data points. For example, think of a two dimensional space with a co-ordinate grid at regular intervals representing a 20km x 20km city. Then imagine creating an outline of a city road network. Each point a LAT/LON co-ordinate. Then imagine placing thematic data such as known traffic hot spots.
Lots of data.
[0] The author has this post in his blog ~ https://peteris.rocks/blog/openstreetmap-city-blocks-as-geoj...
Please don't do things like this. It only encourages people to be lazy about producing conforming documents, and different parsers that try to compensate for syntax errors are going to do so in different ways. We learnt this the hard way with HTML.
Earlier quoted context omitted.
Because it has GBs of data? There's no size limit on JSON.
I think nom-nom is trying to imply that if you're passing GBs of Json around, "human readability" isn't probably a concern. Therefore you could go for an efficient binary format.
Please don't do things like this. It only encourages people to be lazy about producing conforming documents, and different parsers that try to compensate for syntax errors are going to do so in different ways. We learnt this the hard way with HTML.
I'm not quite seeing who you think would be encouraged here. Bad JSON output is usually created in a rush by someone who didn't test their output. It's unlikely that someone who does test their JSON output would become lazy because a few lenient parsers exist.
Or, how I made my service a DDoS target. It's not just the extra compute, it's the lack of a formal specification. If different services applied this kind of ad hoc "postel's principle" they may parse the malformed markup differently, and end up introducing downstream inconsistencies.