On: HTTP: , FTP:, and Dict:?

[kragen]

maybe we could have a format that was more human-readable than json (or especially xml) but still reliably emittable and parseable? yaml, maybe, or toml, although i'm not that enthusiastic about them. another proposal for such a thing was ogdl (https://ogdl.org/), a notation for what i think are called rose trees

> OGDL: Ordered Graph Data Language

> A simple and readable data format, for humans and machines alike.

> OGDL is a structured textual format that represents information in the form of graphs, where the nodes are strings and the arcs or edges are spaces or indentation.

their example:

    network
      eth0
        ip   192.168.0.10
        mask 255.255.255.0
        gw   192.168.0.1

    hostname crispin

another possibility is jevko; https://jevko.org/ describes it and http://canonical.org/~kragen/rose/ are some of my notes about the possibilities of similar rose-tree data formats

[hnlmorg → kragen]

Formats like TOML are horrible for heavily nested data (even XML does a better job here) and the last time I checked, TOML didn’t support arrays at the top level.

YAML is nicer than JSON to write, but I wouldn’t say it’s any nicer to read.

If you want something that’s less punctuation heavy, then I’d prefer we go full Wirth and have something more akin to Pascal.

[kragen → hnlmorg]

arrays at the top level are probably a bad idea for protocols that need to evolve in a backward-compatible way

what do you mean about heavily nested data? do the other formats i linked do a better job there?

i'm not sure it's possible to come up with a data format that will work well for such a wide range of use cases, but it sure would be nice to have. json is pretty great in terms of being able to load it into the browser, or visidata, or python, or js, or whatever

[hnlmorg → kragen]

> arrays at the top level are probably a bad idea for protocols that need to evolve in a backward-compatible way

Depends on the protocol. It might be preferable to version the end point. Or if it’s a specific function, eg list-synonyms” then having a dictionary just to reference an array could be argued as unnecessary protocol bloat. Particularly given the aim of this exercise is readability.

> what do you mean about heavily nested data? do the other formats i linked do a better job there?

I mean a tree like structure.

JSON and YAML are probably the best in class here. XML, for all of its warts, is good at handling nested data in a readable way too.

TOML was more based around a flatter structure.

> i'm not sure it's possible to come up with a data format that will work well for such a wide range of use cases,

It’s not. The moment that happens, that format then becomes unwieldy and people then feel the urge to invent yet another new format to simplify things. It’s a vicious circle that happens over and over again in the tech sector.

[kragen → hnlmorg]

it's a pretty big problem that connecting existing software together so often requires writing new parsers

[hnlmorg → kragen]

That suggests things are getting worse but personally I’ve seen the opposite trend.

These days developers rallying around a subset of established standards rather than inventing new protocols and grammar for each new service.

Take a look at the old protocols out there: finger, DNS, Gopher, HTTP, FTP, SMTP Dict, etc. they all have their own grammar and in many cases, even that grammar is very loosely defined or subject to dozens of different standards. Whereas these days it’s mostly JSON or XML over HTTPS. Or ProtoBuf if you need something more compact.

There’s definitely still room for improvement. For example the shift towards proprietary messaging protocols like Slack, Discord, etc. But that’s another topic entirely.

[kragen → hnlmorg]

yeah, i appreciate the move to html, http, and json. although http/2 and http/3 arguably aren't really http, and scraping data out of html is ridiculously time-wasting. the shift toward cloudflare and secret criteria for blocking users whose sessions act "atypical" are also huge problems, but that's sort of what you'd expect from using software running on remote servers you can't control