Earlier quoted context omitted.
Glad I'm not the only one who reads it that way.
J cough?
Jack off, I'm afraid.
JCOF: JSON-like Compact Object Format
11–20 of 69 posts
Re: JCOF: JSON-like Compact Object Format
#12Neither fully human-editable nor really compact, but an interesting experiment nonetheless.
Nevermind readable
Re: JCOF: JSON-like Compact Object Format
#13People keep reinventing JSON trying to beat gzip, and it never beats the simplicity of gzipping JSON...
Re: JCOF: JSON-like Compact Object Format
#14People keep reinventing JSON trying to beat gzip, and it never beats the simplicity of gzipping JSON...
This actually does. I used Python gzip to see how the minified would compress and came up with 157 bytes to JCOF's 134. Using the same mechanism to gzip the JCOF saves only 4 bytes. I'm actually rather impressed.
Re: JCOF: JSON-like Compact Object Format
#15Re: JCOF: JSON-like Compact Object Format
#16Earlier quoted context omitted.
Jack off, I'm afraid.
Interesting, I wonder which type of English speakers would see that as their initial hunch for pronunciation.
While Oscar Wilde would undoubtedly have something witty to say about that, I guess it's a matter of stress: if you read it as a word and assume stress on the (invisible) first vowel, it's almost inevitable: juh-cof.
Re: JCOF: JSON-like Compact Object Format
#17Serialization formats that dedupe and perform other fancy processing trade increased CPU time for decreased memory usage. People who care about CPU time will want to measure the CPU time hit as well as the memory savings. This format is also not interoperable without a decoding library, which kind of invalidates the comparison to JSON. If you're going to do this, why not just go full binary and save even more memory?
You're decoding JSON in all cases. Usually network dominates over cpu. Sometimes it's useful to have human readable serializations, especially if you expect to operate in anger.
Re: JCOF: JSON-like Compact Object Format
#18JCOF is not usable in many of the use cases where JSON is. Here is why:
* JSON is really schemaless so I don't have to assume all objects are shaped the same or that they are even the same kind of object. This allows for streaming serialization, and does not require the data structure to be known or to introspect data to create the heading lines.
* Nested objects look to be difficult, especially if the schema is not known.
* JSON is very human friendly, JCOF is not.
I do think the format is better than CSV, TSV and other delimited flat record formats. JCOF appears to be able to handle objects that are not tabular, which CSV just can't really do. A replacement for JSON this is not, and storage efficiency isn't really relevant because of the difference in purpose.
Re: JCOF: JSON-like Compact Object Format
#19Earlier quoted context omitted.
curl https://raw.githubusercontent.com/mortie/jcof/main/tests/corpus/meteorites.json | gzip -9 | wc Gives me 34569 So the comparison is: JSON: 244920 bytes JCOF: 87028 bytes GZIP: 34569 bytes
To be fair you would gzip the JCOF encoding in this example too. Author mentions gzip doesn’t work for some use cases. For use case mentioned I’d expect sqlite to be similar, at least that is the default thing I’d reach for. If for some reason sqlite wasn’t sufficient probably a custom binary encoding controlled and updated via code instead of config would be next.
meteorites.json, re-encoded via both JSON.stringify() and jcof.stringify():
json jcof jcof/json
plain 244975 87083 0.355
gzip -6 35829 33152 0.925
gzip -9 34384 32875 0.956
xz -9 27864 28696 1.030
Re: JCOF: JSON-like Compact Object Format
#20People keep reinventing JSON trying to beat gzip, and it never beats the simplicity of gzipping JSON...
comets.json:
JSON: 51949 bytes
JCOF: 37480 bytes (0.721x)
JSON ZIPED: 15178 bytes