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

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

hansvm 10 months ago | parent | next [-]

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 10 months ago | parent [-]

> JSON is [...]

What would you suggest instead given all these cons?

▲

Y_Y 10 months 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 10 months ago | parent [-]

Suggesting protobuf as alternative to JSON is crazy talk.

	▲	egorfine 10 months ago \| parent \| next [-]
		And this is why I was asking the question in the first place. Not that I'm a fan of JSON, but I fail to conceive anything better as a general purpose protocol.
	▲	Y_Y 10 months ago \| parent \| prev [-]
		You must not have seen the abject misuses of JSON I've seen then

▲

wolf550e 10 months ago | parent | prev | next [-]

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

▲

codeduck 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months ago \| parent [-]
		Sure. Between the two comments, I think the SOAP joke is a lot better.