this post was submitted on 15 Sep 2024

22 points (77.5% liked)

Programming

17010 readers

273 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

[email protected]

RFC 7493: The I-JSON Message Format (datatracker.ietf.org)

submitted 3 days ago by [email protected] to c/[email protected]

17 comments fedilink hide all child comments

all 19 comments

sorted by: hot top controversial new old

[–] [email protected] 14 points 3 days ago* (last edited 3 days ago) (1 children)

A summary:

An old proposal (2015, not sure why OP posted it now), that basically proposes to put some more standards and limitations around JSON formatting to make it more predictable. Most of it seems pretty reasonable:

Must be UTF-8 encoded and properly escape Unicode characters
Numbers must respect the JavaScript number Type and it's limitations (i.e. max magnitude of an int etc.)
Objects can't have duplicate keys
The order of keys in objects does not matter
A JSON file does not need to have a top level object or array, it can be any JSON value (i.e. just a string or a number is still valid JSON).
It proposes that when processing JSON, any unrecognized keys should be ignored rather than errored

It recommends:

Specific formats for date-time data
That binary data be stored as a bas64url string

Honestly, the only part of this I dislike is the order of keys not mattering. I get that in a bunch of languages they use dictionary objects that don't preserve order, but backend languages have a lot more headroom to adapt and create objects that can, vs making a JavaScript thread loop over an object an extra time to reorder it every time it receives data.

[–] [email protected] 4 points 3 days ago (1 children)

Personally, I prefer duplicate keys to be eaten by the parser but I can see how it'd be beneficial to prevent them.

[–] [email protected] 3 points 3 days ago* (last edited 3 days ago)

I'm honestly unsure if they intend the 'must-ignore' policy to mean to eat duplicate keys without erroring, or just to eat keys that are unexpected based on some contract or schema....

[–] [email protected] 6 points 3 days ago* (last edited 3 days ago) (2 children)

Why restrict to 54-bit signed integers? Is there some common language I'm not thinking of that has this as its limit?

Edit: Found it myself, it's the range where you can store an integer in a double precision float without error. I suppose that makes sense for maximum compatibility, but feels gross if we're already identifying value types. I don't come from a web-dev/js background, though, so maybe it makes more sense there.

[–] [email protected] 4 points 3 days ago* (last edited 3 days ago)

Why restrict to 54-bit signed integers?

Because number is a double, and IEEE754 specifies the mantissa of double-precision numbers as 53bits+sign.

Meaning, it's the highest integer precision that a double-precision object can express.

I suppose that makes sense for maximum compatibility, but feels gross if we’re already identifying value types.

It's not about compatibility. It's because JSON only has a number type which covers both floating point and integers, and number is implemented as a double-precision value. If you have to express integers with a double-precision type, when you go beyond 53bits you will start to experience loss of precision, which goes completely against the notion of an integer.

[–] [email protected] 3 points 3 days ago

I didn't think you realize just how much code is written in JavaScript these days.

[–] [email protected] 6 points 3 days ago (1 children)

Just skimmed but seems like a decent idea. Not that I've knowingly run into issues parsing JSON too much

[–] [email protected] 6 points 3 days ago (1 children)

It's from 2015, so its probably what you are doing anyway

[–] [email protected] 2 points 3 days ago* (last edited 3 days ago)

It’s from 2015, so its probably what you are doing anyway

No, you are probably not using this at all. The problem with JSON is that this details are all handled in an implementation-defined way, and most implementation just fail/round silently.

Just give it a try and send down the wire a JSON with, say, a huge integer, and see if that triggers a parsing error. For starters, in .NET both Newtonsoft and System.Text.Json set a limit of 64 bits.

https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonserializeroptions.maxdepth

[+] [email protected] -6 points 3 days ago (3 children)

[removed by mod]

[–] [email protected] 16 points 3 days ago (1 children)

Ok.

[–] [email protected] 8 points 3 days ago

Tbh this is a programming community. While yes, a quick summary would not have gone amiss, I don't fault OP for not including it. RFCs are often pretty dry but this one is reasonably straightforward as a subset of JSON to reduce some ambiguity.

[–] [email protected] -3 points 3 days ago* (last edited 3 days ago) (1 children)

Imo the only ones that should feel bad about it are those upvoting it.

Edit: lemmy is mostly low effort stuff and not interesting discussions. So while this post provides nothing of value that is something the voting system is supposed to handle

[–] [email protected] -3 points 3 days ago (2 children)

Yeah, the quality on Lemmy is nowhere near what Reddit was back in its heyday 10+ years ago; mostly due to the quality of the users; users who think content like this is worthy of posting and upvoting.

[–] [email protected] 3 points 3 days ago* (last edited 3 days ago)

Dude, go drink a coffee, and then reflect on what a negative little bitch you're being.

The quality on Lemmy is somewhat worse than Reddit 10 years ago, entirely because the user base is a fraction of the size and is more equivalent to when Reddit was first growing 15-20 years ago. Even then it was only a success because they bootstrapped it using fake posts and comments.

Lemmy is doing great, what it needs to grow is a positive and welcoming community, and then for Reddit to do something stupid again to trigger an exodus.

[–] [email protected] 0 points 3 days ago* (last edited 1 day ago) (1 children)

Yeah, the quality on Lemmy is nowhere (...)

Go ahead and contribute things that you find interesting instead of wasting your time whining about what others might like.

So far, all you're contributing is whiny shitposting. You can find plenty of that in Reddit too.

[–] [email protected] -2 points 2 days ago (1 children)

You're clearly one of the reasons the quality is so low. Wasting everyone's time using lemmy as your personal link aggregator. It's obnoxious af.

[–] [email protected] 2 points 2 days ago* (last edited 2 days ago)

Please be mindful of fellow community members and our TOS when making posts/comments on our communities.

As stated in our TOS:

1.4. You are responsible for your own experience on our services.
1.7. You are expected to follow our Code of Conduct
- 1.1. Remember the human: When interacting with other people on the site they should be interacted with as if they are a human, that is with respect and in a way that you would want to be treated.

Please be respectful and mindful of others when making posts and comments towards others.
Consider this your first warning.
Thank you.