> import JSON (something I use as little as possible)

This makes me wonder what world of development she is in. Does she prefer SOAP?

JSON is slow, not particularly comfortable for humans to work with, uses dangerous casts by default, is especially dangerous when it crosses library or language boundaries, has the exponential escaping problem when people try to embed submessages, relies on each client to appropriately validate every field, doesn't have any good solution for binary data, is prone to stack overflow when handling nested structures, etc.

If the author says they dislike JSON, especially given the tone of this article with respect to nonsensical protocols, I highly doubt they approve of SOAP.

▲

egorfine 2 days ago | parent [-]

> JSON is [...]

What would you suggest instead given all these cons?

▲

Y_Y 2 days ago | parent [-]

Fixing all of those at once might be a bit too much to ask, but I have some quick suggestions. I'd say for a more robust JSON you could try Dhall. If you just want to exchange lumps of data between programs I'd use Protobuf. If you want simple and freeform I'd go with good old sexps.

https://github.com/dhall-lang/dhall-lang

https://protobuf.dev/

https://en.wikipedia.org/wiki/S-expression

▲

imtringued a day ago | parent [-]

Suggesting protobuf as alternative to JSON is crazy talk.

	▲	Y_Y a day ago \| parent [-]
		You must not have seen the abject misuses of JSON I've seen then

▲

wolf550e 2 days ago | parent | prev | next [-]

Her webserver outputs logs in protobuf, so I think she likes binary serialization.

▲

codeduck 2 days ago | parent | prev [-]

Given her experience and work history, it's much more likely that she views any text-based protocol as an unnecessary abstraction over simply processing raw TCP.

▲

horsawlarway 2 days ago | parent [-]

Is this a joke? I don't even know where to begin with this comment... It reads like a joke, but I suspect it's not?

TCP is just a bunch of bytes... You can't process a bunch of bytes without understanding what they are, and that requires signaling information at a different level (ex - in the bytes themselves as a defined protocol like SSH, SCP, HTTP, etc - or some other pre-shared information between server and client [the worst of protocols - custom bullshit]).

▲

dmwilcox a day ago | parent | next [-]

__attribute__(packed) structs with an enum at the front indicating their type. The receivers use a switch to figure out which sub-message to interpret the strict as...

It isn't pretty and you better be able to control the rollout of both sides because backwards compatibility will not be a thing. But I'll take it over a giant pile of code generation in many circumstances

▲

lesuorac 2 days ago | parent | prev | next [-]

> or some other pre-shared information between server and client [the worst of protocols - custom bullshit])

Why is this worse than JSON?

"{'protected': {'protected': { 'protected': 'QABE' }}}" is just as custom as 66537 imo. It's easier to reverse engineer than 66537 but that's not less custom.

▲

codeduck 2 days ago | parent | prev [-]

parent mentioned SOAP as an alternative to JSON. I was being glib about the fact that the engineer who wrote this blog post is a highly-regarded sysadmin and SRE who tinkers on things ranging from writing her own build systems to playing with RF equipment.

	▲	horsawlarway 2 days ago \| parent [-]
		Sure. Between the two comments, I think the SOAP joke is a lot better.