It does no runtime memory allocation, and since it doesn't depend on libc and has a very small size, it can be used on highly resource-constrained embedded processors.
Sorry, but no. Shuffling around strings is all fine when you're writing Javascript and have GHz and GB of RAM at your disposal, but that stuff just doesn't fly when you need to conserve RAM and especially need to have easily determined time and space constraints.
JSON just doesn't fit that profile. Neat implementation, but don't give the impression that any of this would help with embedded.
"embedded" is a big market and isn't always constrained to be hard-realtime. I spent years as an "embedded" developer at chumby industries and ended up having to use JSON fairly frequently.
Sometimes you don't get to choose what the source format is because you're consuming someone else's data feed, and if all they offer is JSON, you parse JSON. Also, on a 400-ish mhz ARM with 64 MB of RAM parsing reasonably sized JSON data is no big deal in native code.
You need to further qualify your comments beyond just "embedded" because what you're now talking about (very low mhz, KB of RAM) is a niche within the larger embedded world.
Even with GHz and GB of RAM, I've seen enough JSON C parsers which leaks memory over time. There are other issues like how efficient is the memory manager (either malloc or others), etc. IMO, getting rid of memory allocation is definitely an shift toward making a reliable json parser.
Are you willing to categorically claim that there is not now, and never will be, a situation in which someone must process JSON and would prefer to do so with an extremely wimpy chip? And by "extremely wimpy" I mean the same thing you do: clock speeds measured in single- or double-digit MHz, code on something like NOR flash, and maybe a kilobyte or two of RAM if you're lucky.
Sure, it sounds like a bad idea, but it wouldn't be the first time someone has had to do something crazy for compatibility with someone else's stuff.
Why wouldn't this help with embedded? Are you saying it's never a good idea to use JSON for data transport within any embedded system? That would be a bold claim.
For me, that means code space and RAM measured in kilobytes, cycles in MHz. Most people don't realize that serializing data (most importantly, floating point numbers) to strings is a complicated and time-intensive matter. Even a limited printf implementation can easily cost you many kilobytes. Not to mention it introduces you to C's most special hell: variable length memory blocks containing strings.
The one thing that embedded gives you is a lot of control about your computing environment. Just sending around binary data is a very viable thing to do under these conditions. Not so for JSON; its single biggest selling point is that you can use it in every platform out there. Its the oldest tradeoff: giving up flexibility allows you to use more constrained processors (and save money).
What embedded machines are we talking about? The processor in your smartphone is not resource constrained, its just power constrained. Thats a very different tradeoff.
