4 ms·

Show HN: The Bare Message Encoding

36 points by ddevault 6y ago

fiatjaf 6y ago
All my life I've been searching for this thing. I thought my only choice was either to include the schema in the message (JSON, CBOR, MessagePack) or use bloated code-generation tools made by Google people who don't care about simplicity and ease-of-use (Protobuf). Apparently I was wrong and finally someone invented the Holy Grail of structured data encoding.
cxr 6y ago
> stateless tokens tend to be a lot larger than their stateful counterparts. [...] Here’s an example: the cursor fields on the new GraphQL APIs are stateless. This is one of them: [...] A whopping 141 characters long! It’s hardly as convenient to lug this monster around. Most of the time it’ll be programs doing the carrying, but it’s still annoying when you’re messing with the API and debugging your programs. This seems to be a consequence of the failure to really grok the Tao of HTTP. Specifically, the belief that this stuff should be "sequestered" into a blobby token in the first place is just starting off on the wrong foot and asking to be frustrated—in exactly the way that the blog post goes on to describe. Want to deal with authorization and/or authentication concerns? Mandate that the request carries the right headers. HTTP can already accommodate that, and if what's in the RFCs isn't a perfect fit for your needs, then extend the semantics until it can do what you want and then document exactly what your use case is and how your design solves it. It's hard to say more, since the post doesn't really include examples of decoded payloads, i.e., what this is all actually being used for, but in principle really embracing HTTP is the way to go, rather than merely using HTTP as the transport layer for a half-baked attempt at RPC. It reminds me of the really poor design that the Git project settled on for trying to manage the transition from the legacy "dumb" protocol to the newer (less chatty) "smart" protocol—opting to probe for support by tacking a query string on the end of the resource identifier. Except HTTP already has a good way to do content negotiation, and not all legacy servers respond the same way to unexpected query strings (i.e., by ignoring them). So the end result is that you can have a functioning server that fully supports the dumb protocol, but when you try to push to it with the git CLI, the exchange fails because as far as the server is concerned, it's seeing the client asking for a resource that the server doesn't know anything about. https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protoc... Perhaps more apropos, in a "general lessons in computing" sort of way, is Chip Morningstar's anecdote about Fujifilm failing to get the results they wanted out of Habitat/Xanadu as a consequence of "losing the architecture": http://habitatchronicles.com/2004/04/you-cant-tell-people-anything/ http://habitatchronicles.com/2004/04/you-cant-tell-people-an...

36 points by ddevault 6y ago

All my life I've been searching for this thing. I thought my only choice was either to include the schema in the message (JSON, CBOR, MessagePack) or use bloated code-generation tools made by Google people who don't care about simplicity and ease-of-use (Protobuf). Apparently I was wrong and finally someone invented the Holy Grail of structured data encoding.

cxr 6y ago

> stateless tokens tend to be a lot larger than their stateful counterparts. [...] Here’s an example: the cursor fields on the new GraphQL APIs are stateless. This is one of them: [...] A whopping 141 characters long! It’s hardly as convenient to lug this monster around. Most of the time it’ll be programs doing the carrying, but it’s still annoying when you’re messing with the API and debugging your programs. This seems to be a consequence of the failure to really grok the Tao of HTTP. Specifically, the belief that this stuff should be "sequestered" into a blobby token in the first place is just starting off on the wrong foot and asking to be frustrated—in exactly the way that the blog post goes on to describe. Want to deal with authorization and/or authentication concerns? Mandate that the request carries the right headers. HTTP can already accommodate that, and if what's in the RFCs isn't a perfect fit for your needs, then extend the semantics until it can do what you want and then document exactly what your use case is and how your design solves it. It's hard to say more, since the post doesn't really include examples of decoded payloads, i.e., what this is all actually being used for, but in principle really embracing HTTP is the way to go, rather than merely using HTTP as the transport layer for a half-baked attempt at RPC. It reminds me of the really poor design that the Git project settled on for trying to manage the transition from the legacy "dumb" protocol to the newer (less chatty) "smart" protocol—opting to probe for support by tacking a query string on the end of the resource identifier. Except HTTP already has a good way to do content negotiation, and not all legacy servers respond the same way to unexpected query strings (i.e., by ignoring them). So the end result is that you can have a functioning server that fully supports the dumb protocol, but when you try to push to it with the git CLI, the exchange fails because as far as the server is concerned, it's seeing the client asking for a resource that the server doesn't know anything about. https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protoc... Perhaps more apropos, in a "general lessons in computing" sort of way, is Chip Morningstar's anecdote about Fujifilm failing to get the results they wanted out of Habitat/Xanadu as a consequence of "losing the architecture": http://habitatchronicles.com/2004/04/you-cant-tell-people-anything/ http://habitatchronicles.com/2004/04/you-cant-tell-people-an...