3 ms·
I’d skip protobufs too. They’re horrible for performance. Many data center apps blow more cycles there than on compute. For actual applications where performanc
by redshirt 9y ago
I’d skip protobufs too. They’re horrible for performance. Many data center apps blow more cycles there than on compute. For actual applications where performance is necessary, binary “strict” formats are he only way to go. Protobufs are nice for ease of use, but they’re horrible otherwise.
- swalsh 9y agoMaybe there's a middle ground between the 2.... like ASN.1
- ci5er 9y agoYou mean a self-describing compact schematized format that's been around for 3 decades? Please promote this as hard as you can. Then, us old guys getting aged-out of industry will be able to get jobs again.
- teddyh 9y agoYou’d need to repackage it in some form to make it palatable for modern audiences. Let me take a quick stab. Make “ASN.2” or something, update the fundamental data types to modern standards (think of what changed from NeXTSTEP to macOS X; they changed from TIFF to PNG, from PostScript to PDF, etc. but kept the overall architecture the same). Consolidate and simplify the many options (but do not eliminate options entirely). And call it… JASN or something, which sounds like both JSON and ASN, and make up some acronym where the “J” stand for “Joint” (like in JPEG, which stands for Joint Photographic Experts Group). And, maybe most importantly, make freely licensed tooling available for both converting to and from ASN.1 and JSON, but also jgrep, jless, jcat, etc. (similar to zgrep, zless and zcat, etc.) Make these packages available for all common operating systems, readily installable using that plaform’s usual mechanism.