Re:MessagePack: like JSON, but fast and small
by gnulinux on Tuesday March 10, 2020 @03:54PM
(#22538978)
Compression is not encryption and security by obscurity is bad practice. So it doesn't matter if the data is json or compressed or protobuf or messagePack or custom struct. As long as it's not properly encrypted, it's just plaintext.
Re:MessagePack: like JSON, but fast and small
by ludocode on Tuesday March 10, 2020 @07:26PM
(#22541115)
I don't think the parent poster was confusing encryption for compression or suggesting security by obscurity. He just meant that JSON is never sent in pretty-printed plain text over the wire, so you always need tooling to view it.
This has been my experience with JSON as well. Almost all JSON in the wild especially in web services and RPC is at least minified, so you need to pass it through something like `python -m json.tool` to reformat it for viewing. So you might as well use MessagePack and pass it through `msgpack2json -d` to view it instead. It makes no difference whether the underlying format is human readable.
(Except if you want to use JSON for configs, which a strongly recommend against for a bunch of reasons including missing support for comments).
I mean by now nearly all times you send thinks over the wire they are ecrypted or at least compressed. So inspecting on-wire messages without "proper" more complex tooling doesn't really work. But if you have already more complex tooling involved there is no reason why you need to be able to read the raw message, it could be just converted on-the-fly into a readable format.
Same applies for application development when e.g. logging, you always do some formatting/conversion when logging some data, so not a problem to convert msg-pack to a human readable format. But then today logging of e.g. servers should always go to some form of log server which does add features like search ability by indexing the log and similar. So no problem to have a msg-pack viewer there, too.
Honestly I believe the only reason human readable formats made/(still do make sometimes) sense was due to limited tooling sometimes caused by server limits in computation power on the developers system. And the fact that many binary formats are totally over engineered making handling of them painful. Especially debugging of slightly corrupted data. Which isn't the case for MsgPack.