4 ms·
> I also want to welcome things like gRPC/Protobuffs over HTTP/2 which introduce really fast comms between clients and servers, sacrificing the visibility of th
by sebcat 8y ago
> I also want to welcome things like gRPC/Protobuffs over HTTP/2 which introduce really fast comms between clients and servers, sacrificing the visibility of the stream's contents.
Protobufs and similar serialization protocols are great for complex data. It is worth pointing out that we've had ASN.1 for a while and it's pretty fast too, at least for limited subsets of OIDs/types, in certain encodings, though XER or JER would probably not compete with BER.
HTTP/2 is a complex protocol designed to fix problems with the way people build websites today. A lot of its features does not make sense/is not needed for simple message passing.
e.g., some HTTP/2 implementations will probably see HPACK DoS bugs/vulns because HPACK is stateful, whereas if HTTP/2 wouldn't have HPACK that problem would not have existed, but the reason why HTTP/2 has HPACK is because people bloat headers with tons of stuff.
IRC works and works well for its use case. Apart from newline-delimited strings - netstrings and TLV are other examples of formats that can build great, simple and introspectable/open formats.
I'd venture a guess and say that an RFC1459 PRIVMSG message parses faster than a protobuf message carrying the same information - due to parsing an RFC1459 PRIVMSG message is so simple. Of course, if you want arbitrarily sized messages, or messages with an arbitrary number of nested messages inside it you need more complexity.