9 ms·

It should only be easy to debug and accessible to humans when needed IMO. I really think it should be possible to load a "production message", log event or what

• satanspastaroll 7y ago
  Even switching between modes may introduce new kinds of undefined behavior, which may not be visible on the text-only side
  • kstenerud 7y ago
    Every extra step in the process adds another potential failure point. But we're fast approaching a data and energy crunch that will push the industry towards binary formats once more. This is my attempt to keep that shift sane, and avoid the mess of the 80s and 90s. The implementations are almost done now, and my first tool will be a command line utility that reads one format and spits out the other, so that you can take a binary dump from your production system using tcpdump or wireshark or whatever, and then convert it to a human readable format to see what's going on. I'll probably even put in a hex-reader so that you can log the raw message and then read it back: 2019-10-02:15:00:32: Received message [01 76 85 6e 75 6b 65 73 88 6c 61 75 6e 64 68 65 64 79] $ ceconv --hex 01 76 85 6e 75 6b 65 73 88 6c 61 75 6e 64 68 65 64 79 v1 { nukes = launched }
    • satanspastaroll 7y ago
      I doubt there is any significant crunch coming from just encoding/decoding the stream. Most of the time comes still from waiting for network resources, and evaling megabytes of add-in JS. Now the same problem applies to JS, and the counter argument for openness and usability are still the same. Compressed transmission and binary parallel transmission in HTTP/2 are also helping with the comms size. The project still seems cool, I'll have to have a deeper look into it soon